110 Year Policy

Gathering Information

INTERVIEWING
First thing I did was interview several support staff to understand what they were doing to resolve cases. By watching them I quickly saw a pattern; they would check the relationship between the person who requested the action and the person whom it was requested for. If they are related then they would approve the request. If not they would deny it. 50% of the time it would be denied.

ANALYZING THE FLOW
I needed to understand why people were unknowingly requesting this action. As I analyzed the user’s flow I noticed the call to action was similar to another call to action for a parallel flow. The call to action that required the support staff to review was “Request permission”. The call to action that didn’t require the support staff was “Request”. How in the world is a user supposed to know the difference between those two call to actions? They are pretty much saying the same thing. No wonder 50% of cases get denied. People don’t know what they are clicking on.

Finding Solutions

JUST A TEXT CHANGE
Change the call to action to clearly describe what the user will get. We changed it from “Request Permission” to “I have permission.” This helped users understand that they have to already have permission from a person to complete this action. They were not requesting permission from FamilySearch they were requesting it from other users.

AUTOMATING
We had all the technology to build a system that would automate most of what a support staff was doing. They would manually look up relationships when the system was doing that automatically in other places. There were times when a case would need to be reviewed manually. We made sure we thought through those use cases and created the flow chart above image 1.1. This way we could ask users specific questions so we know what needs to be review and what doesn’t.

Changes to the Users

UPDATING UI

The form for this request went from a static form with little room for variety to a dynamic form that would allow for multiple paths so the system would know when to auto-approve a case and when to have it reviewed.

The Impact

MUCH QUICKER
This has made a big impact on our support staff. We have seen a 25% decrease in cases created and 38% cases that were created were automatically approved. That is a significant work load taken off support staff. Users are loving the automatic approvals and that they can continue their work much quicker.

One month after automation Cases created 30,300 | Auto-approved 10,500 | Review required 20,000