User Workflow Mapping: Internal Tools Assessment

Simply put, a workflow is meant to chart the steps a user takes when getting work done. Our operations team had been advocating for years (literally years!) for new internal tools that would streamline their workflows, and now that the company’s growth was at 2x, it was deemed time.

We had two options: 

1. Keep and update our own internal tools.  That meant keeping our custom CRM and a supply-demand visualization system.

2. Find something better. That could mean a contract with a CRM like Salesforce or Hubspot.  But changing systems over would be quite costly.

Research Plan

I was tasked with evaluating our current workflows team-by-team so that we had an understanding of our internal processes/needs and could then evaluate existing market solutions that could fill those needs. Timeline: 2 weeks

The plan:

1. Interview each team to map out current workflows. I had each employee narrate their process as they worked through their regular workflow. I also recorded how many times they switched between one system to another. Taking screenshots throughout helped me bring these flows to life. I tried to be as unobtrusive as possible (the Hawthorne effect is real).

2. Document and peer check workflows. After an initial attempt (I used Figma), I then went back to each team to make sure what I had recorded was indeed correct.

3. Analyze findings and identify areas of improvement: The goal here was to look for gaps, overlaps, etc. To do this, I tried to find user’s work-arounds for failing features (notes on the whiteboard, a mind-map for locating customer emails). Seeing how many times users switched between tools was also helpful.

4. Present back to key stakeholders. This was namely our Ops and Product team responsible for making decisions on next-steps.

Employee Interviews

I interviewed 11 teams and mapped out their workflows. Going in, I knew I’d have to map out workflows by task and not by role. For example, I knew that a Care agent could be rescheduling a move, starting a claim, etc., and those were very different workflows. I also wanted to account for “fringe” tasks. These tasks take up less than 20% of the workday, but I wanted to make sure that they didn’t account for 80% of profits (the old 80:20 rule).

So in summary, I mapped each team’s workflows by task and labelled task importance on a scale of 1-10.

I also asked each team the following questions to help get at the bigger goals and frustrations in their work:

1. What are you thinking when you do x? What are you feeling when you do x?

2. Tell me what tasks you perform each day. Or, if it helps to think of it another way, how would you write your job description?

3. What’s the ideal state for your role? In other words, if you could wave a magic wand over your day-to-day tasks, what would you change?

Document and peer check

At this point, I had about 30 task flows. I took these back to each team and asked for specific feedback related to the following:

1. Is anything missing from each task flow?

2. Is there any other work you perform during the day that hasn’t been recorded?

I made copious notes and updated each flow.

I also turned each of these flows into a story. Here’s an example.

Ops Taskflow for a “No-Show”:

1. Ops employee, let’s call him Tim, logs in and sets himself as available on Talkdesk. 

2. Tim gets a call from a lead about a no-show, meaning a mover who hasn’t shown up to a job.  After the call, Tim selects a disposition for that call. 

3. Tim reaches out to the no-show, who says he’s injured and can’t make it.  Tim explains the no-show policy.  

4. He updates the thread in Kustomer, which documents conversations between customers and our care team.  This lets the customer know that we’re looking to find a replacement.

5. Tim uses an internal tool named Pitbull to find that order.  He sees the lead who called in is on an afternoon job, so if a replacement is not found, that move could delay the next job as well.  

6. Tim clicks on the order and removes the mover from the order.

7. He selects reasons for the unassignment in Iron Patriot, in-house CRM.

8. Next, he turns to Google sheets to find out how much he can bonus someone for a rushed move like this. 

9. Then back to Pitbull to search for available movers—these are guys who have set availability for today.  Several of them are already on a move, though, so there’s only three guys left. 

10. Tim composes a message in Kustomer, copies the phone number from Pitbull, and sends.

11. Copy same message in Kustomer, copy another number from Pitbull, send.

12. Copy and paste until either someone claims the job or there are no more options left.

13. Woohoo!  Someone picked up the job. Tim is notified through Kustomer.

14. Tim adds the new mover to the order back on Pitbull.

15. He updates the lead mover on Talkdesk to notify him that help is on the way.  Tim selects a disposition after finishing the call.

16. Tim updates the thread in Kustomer to notify the customer that a replacement is on their way.

17. He heads back to Pitbull to check to see if the no-show should be frozen or deactivated.

18. Tim changes that mover’s status.  

That’s 18+ steps, 5 tools, and 14 switches back-and-forth between those tools. Oy… it wasn’t looking great. Here’s the screenshot flow of the same.

Analyze Findings & Identify Areas of Improvement

I went through each flow and all of my interview notes on employee’s goals and what they were thinking, doing, and feeling as tasks were performed. I came up with the following:

• Desire for more insights: There was no clear visibility into who had edited something on a customer’s order or how long actions were taking. This meant lack of performance tracking and reporting. It was also a cause of miscommunication.

• Automation: For example, when rescheduling a customer, the Care team would also have to consult with the Truck team when changing the date for a customer’s move.  A manual inquiry had to be made to the Truck team and back and forth until the case was resolved.  That meant simple tasks like rescheduling a move took more than one phone call (poor customer experience) and led to multitasking (loss of productivity).

• Search functionality: No ability to search by customer email for example.

• Customizable dashboards: This meant our market managers had to rely on google spreadsheets and queries for flagged orders or orders with low reviews. There was not a dashboard or a report that compiled these findings for them.

• Intuitive on-boarding: The training manuals for new employees were upwards of 30+ pages with employees balancing sometimes 10 or more tools. This meant scaling would always be difficult, not to mention all the switching back-and-forth to perform simple tasks. 

Present back to stakeholders

I started with a story. I wanted to make it more visceral for our stakeholders because the success of our company was also wrapped up in the success of how well our employees could use our tools. So I asked one of our Daily Ops Team members to go through the deck of screenshots to paint that picture. I wanted stakeholders to feel the mental cost of switching back-and-forth between tools, to get a feel for the time it takes to perform a task, and to feel (if only for a second) how frustrating and inflexible our current processes were.

I then went through each team’s workflows and also presented a deliverable on employee’s behaviors—what they were thinking, doing, and feeling. I had hoped by using both the task flows and my notes from interviews that I could present more of the person behind each flow. I didn’t want our conversation to only be about workflows: “here’s what our employees do.” That’s not the whole picture.

I ended with a question: “What are our opportunities here?” I wanted this to be a collective discussion since my views were limited, so I invited stakeholders to share their own insights. I added their insights to the list I had compiled.

In summary, this was generative research at its best—only defining the problem at hand but not presenting any sort of solution. Even though I was only tasked with providing workflows, I hoped that providing a more complete picture would “stick,” and that stakeholders, when evaluating product solutions, would consider employee’s well-being more than a productive workflow.