For more on Scaling teams see here.

Automation vs the human touch

How can we make request and response practices both efficient and personal? This is a challenge for any team, and one that becomes harder when scaling teams. This is because the manual ways of working that function well with a small team (e.g. using a shared email inbox) become more laboured and harder to manage with a larger team and the volume of standard requests lends itself to an automated approach such as a Service Desk.

But which of us actively enjoys engaging with a Service Desk system as a user? And if we don’t like it, will our stakeholders?

Using my current team as the example we have broadly four types of request that come into the team regularly:

1. Requests for access to the Tableau server
2. Bug reports or requests for changes to existing dashboards
3. Requests for new dashboards or pieces of analytics and insight work – strategic or operational level
4. Ad hoc requests for analytics support and advice from those doing their own analytics work

Example 1
The only one of these that has any automation in request processing is no. 1. However, the current version of that process has combined email correspondence and an automated form to fill in. It doesn’t work clearly or smoothly for users and therefore gives (potentially brand new) stakeholders an experience of the worst of both worlds.

We have not yet implemented a solution here but I’ve been thinking through an approach:

• Map the user journeys through whatever request systems you have. We care most about our stakeholders having a good experience and secondly about ease of process for the team.
• Prioritise the worst and busiest channel – in our case it is the request for Tableau Access.
• Outline all the steps in the journey and how they work, finding out the context and history for why it is the way it is. Team members have made decisions in good faith getting us to this point, we need to be mindful of that. If at all possible, also ask users directly about their experience of the process.
• Create solution options that use either entirely human or entirely automated processes so you are clear on the differing paths.
• Then if wanting to create a combination, to increase human touch in the automated route or automation in the human route, map the process options from the user point of view first and the team view second.
• If you find yourself saying ‘we can’t do that because the system doesn’t let us’, pause before implementing that system-based approach you’ve come up with because you have hit an instance where you are compromising user experience for team or system experience. Do you really want to make that compromise?
• Think of ways to hide automation within your human process so that a user would not necessarily be aware of the automatic processing but the human gets to save time. For example using standard email responses topped and tailed by a person dealing with the query.
• Think of ways to embed human touch into your automatic process e.g. an online form that is written in a friendly human tone.

Example 2
We also want to improve communication around request types 3 and 4. We have already been able to cut down a huge amount of ‘fire-fighting’ work in the team by meeting analysis and ad hoc requests with a standard set of questions for the requester to write answers to. This not only helps the team obtain more concrete and more detailed information about the request asynchronously (i.e. it doesn’t require a meeting unless the stakeholder is really stuck for where to start), it also provides a valuable exercise for the stakeholder in clarifying their own thinking. We’re now wanting to see if we can structure this process slightly more by having a form to fill in, rather than simply asking the questions via email.

Key questions we always look to include are below and we try to use friendly plain English:

1. What are you working on and what is the overall objective you are working towards?
2. Who is the work to be delivered to – who are the main stakeholders?    
3. What will the stakeholders be using the information for? 
4. If this is for dashboarding, what kind of regularity is the reporting for? 
5. Tell us about the analysis you need. What questions do you want to answer? What measures do you want to visualise? 
6. Where is your data coming from? Tell us about your data sources. 
7. What timeframe are you working to? 
8. What other context can you give us? 

What are our next steps?

Example 1: I’m going to be working on improving the Tableau Server request process so that it is smoother and quicker for users and keeps the ability for them to have human interaction where this is valuable. I believe that if we achieve this, we will have a process that is quick and easy for the team as well.

Example 2: We’re now wanting to see if we can structure this process slightly more by having a form to fill in, rather than simply asking the questions via email.

---

Photo by Susan Q Yin on Unsplash