Creating an Internal Process Map for Customer Support

What is an Internal Process Map?

An internal process map can look quite different depending on the organization and industry. For this approach, we are discussing customer support for a technology company, however most customer support processes will look somewhat similar depending on the products and services offered.

I like to define an internal process map as a predetermined set of steps to follow internally for when a customer reaches out. IBM is a bit more succinct than I am, and they define a process map as “(A process map) outlines the individual steps within a process, identifying task owners and detailing expected timelines”

IBM and I can both agree that it’s the steps within a process and clarifies who does what and when. One of the main goals of a process map is to also reduce ambiguity, not increase confusion. If someone reviews your process map and has more questions after reviewing than they did before about the process, you’ll know you want to revamp your map.

It’s important to note that this article is going over a process map from an internal point of view, but you can easily spin this to create a process map from a customer standpoint and use it in addition to a customer journey map.

What Makes Up a Process Map?

A process map is a bunch of steps, but these steps are not exactly linear as they have contingencies built in for things like “if X happens, then do Y, but if W happens, then do Z”, instead of just a simple 1, 2, 3 numbered list.

A strong process map will consist of a start point, an end point or multiple end points, and lots of different contingencies in between. They typically have literal “yes” or “no” questions too to help move things along and determine the best path. They tend to not use things like “maybe” as process maps are designed to reduce ambiguity and not add to it.

Let’s look at an example from creately.com, called “ Astrid Customer Support Flow”.

As we can see, they have a clearly defined “Start” and then multiple end points depending on the routes taken. To break this down further, we can see that right after “Start” they have several ways customers can contact them, but they are both added to the request tracker so all those methods are noted and added into the one “Request Tracker” path.

From there, they ask simple “Yes, or No”, and depending on the answer you either go left (”Is this a support request” - Yes, go left), or right (”Is this a support request? No, go right).

If it was a support request, then you can see it opens up a whole new side of the map on the left hand side. It continues along on that side until someone assigns the ticket to themselves and solves it, or assigns to someone else who solves it.

On the other side, if it wasn’t a support request, but was a feature request, then it gets added to the backlog, users are informed and then the ticket is closed. If it’s not a feature request or support request, then the ticket is assigned to someone else entirely.

This is a great example of a simple process map as it has that “Start”, multiple “endings” and lots of “yes” and “no” or “if X happens, do Y’ scenarios included to remove that ambiguity that often comes with support requests.

Another Example

This one is from Visual Paradigm Online and you can see that this again has the hallmark characteristics with a “Start”, multiple endings and “Yes” or “No” questions throughout to determine the route taken.

As this is a different example and presumably for a different company, you can see that their map begins with which team or person to assign to and then continues from there, whereas the first example ends more so with whom it is assigned to. Neither is right or wrong, just different approaches that outline their own unique processes, which is exactly the point of a process map.

How to Make Your Own Process Map

In order to make your own process map, you will need your own end goal or process that you are trying to define. For example, in customer support, this process often centers around, how do we receive incoming tickets, who handles them and what do we do?

Once you have the defined end goal, it’s time to start at the beginning. Here are some good guiding prompts to consider when you’re making a process map:

• How can customers contact you? Chat, phone, email, social media, etc?
• Who responds to their initial queries and how quickly?
• Depending on the query type, what team/person handles the request?
• If that person/team handles it, is it solved? If they can’t solve it, what’s next?
• What is considered complete or marks a ticket as solved for your org?
• Any follow up tasks after the ticket is complete (surveys, etc)?

A Final Example

Below is a modified example that I’ve used in the past here at Fishtank. Because we provide estimates for a lot of work, we needed a path to ensure that the estimates are agreed upon before commencing work. The map below clearly shows the following points:

• How clients can contact us
• What our first step is thereafter
• What we need internally and or from the clients to continue
• The estimation and approval process
• What happens if an estimate is denied
• What happens if an estimate is approved
• Work begins
• Regular updates and tickets completed.

This is unique to our company and our needs, but it works in this example as it suits the type of work we do.

Final Points on Internal Process Maps

There is a lot of ambiguity in the world, and often times even for things that don’t need to be ambiguous. If you’re running a customer support team, or work in another industry that is dire need of system processes, I’d highly recommend creating a process map. A process map when done properly will remove that ambiguity, streamline your process and increase efficiency and brain drain as it removes a lot of potential over think for customer support agents. What are you waiting for? Try it with your team today!

---