Call me!

I was going to start this article with ‘If you’re a multi-national, look away now’ as I talk about contact centers, but a few things make this statement wrong.

Firstly, in this connected world we live in if you’re online then prepare to be international.

Secondly, I have the firm belief that every business unit has a contact center. It’s true that without customers you have no business, even internally. And when you have customers you have contact and if you’re a kicking team with lots going on (of course you are!) then you’ll have lots of contact, possibly too much to handle in the daily grind of getting things done.

This article is a tale of setting up a small contact center that served a national business, bourne of a development team that couldn’t complete a task because they were being interrupted to handle support far too much. If your phones are off the hook and you’re spending all day replying to emails to the point you’re working late every night, then I hope you get some ideas about the approach from this article. If not, reach out and we’ll talk about some time and motion work that’s well worth the effort.

The easiest way to describe the setup is to start at the end and work back, so have a look at the diagram below, most of it is going to be straight forward:

To go through the finer details read on.

Front Line

First off, your front line is key. If you’re not planning on having a full-time front-line team member the role still exists. I’ve seen teams struggle with this – simply put, if you’re taking heaps of contact funnel it through a dedicated point. This might be an email inbox, redirecting your calls to a single phone number, or a custodian of knowledge (read on for that).

If no one wants to do it, roster it – everyone should be sent to the front at least once!

Key to this role:

•  Front line role is to field calls and avoid escalation
• They are the custodians of knowledge transfer
• They are responsible for building call avoidance tactics (customer uses knowledge base, online training, etc)
• They prioritise calls. The customer can indicate, but opinion and response are separate (an article on that another time)
• They handle ‘P4’ issues
• They are informed directly of all P1 and P2 alerts

Call Type

There are lots of ways to categorise calls, but for an inbound support team there are two main ways to categorise contact, stuff that needs to be done or information that needs to be shared. In this model we have:

How do I? – Obvious this is the transfer of information from you the experts in your field to the customers, experts in what they’re trying to do.

Break Fix – I use this to describe when an action needs to be done. “Hold on, I’ll just…” if you’re saying this then consider it a break-fix – you’re traveling down this path.

And why do I split the types like this, it makes it easier to do the next bit…

How do I

I reflect here on a statement by a learned CEO early in my career, “the best support query is the one you never get”. Which on the face of it could be a very bad thing, but it was in the context of self-help and ultimately staffing of the support team. Your support team needs to be focussed on call avoidance. Your customer probably doesn’t want to phone in for this type of call (note, the break-fix they absolutely will), they probably don’t want to sit through an hour-long show and tell video either.

You’ll know what works for your team and customers of course, but I’ve found making the support team focussed on tools to avoid calls has many benefits, including;

•  They seek to understand the customer and how they want to be communicated with
• They learn about the systems and processes they support on the way through
• They can use that same content in their call handling process

This last point is key. Setting the support team’s KPIs to include 80% of support responded to with an article or link to knowledge is a key driver in turning your support team from a help desk to custodians of knowledge.

You start to train your customers too, with the sharing of knowledge you bring your customers on the journey. If you’re smart you’ll categorise your knowledge articles the same way as you do your support queries so you can start to measure the effectiveness of published content in reducing your inbound queries too.

You'll notice the 'Analysis' line linking into the work stack. Once you have a decent handle on your inbound how-to request you should start to see how you can change your systems to reduce them. This is the ultimate call avoidance of course, but not one owned by the support team, though they surely should be responsible for identifying these opportunities.

Break-Fix

This is where you’ll have a list of things to do and likely some order in which you want to prioritise them. Even if you don’t it’s a good idea to do something like this so you can reflect on the experience the customers are having.

The order I’ve used in the past is this:

• P1 – Basically all stop – this is when you light the fires
• P2 – App down – when an entire function is unavailable, but business continues (e.g. your commerce site is offline, but you can still send out orders, see below for why this isn’t a P1!)
• P3 – Significant issue – Something is broke, but can be worked around (“Can’t print” is a good example)
• P4 – Request – something the customer is requesting. Password reset is a classic here, though an interesting one.
• P5 – Development idea/request – this is when someone doesn’t have an issue but does have an idea. And it can be anyone.

To go through the above, why is a commerce site offline not a P1? It will be for those involved for sure. The product manager will be going nuts no doubt, the exec team will be twitching in their bonus boots. But the consumer (at least for a bit) isn’t likely to stress too much. And in fact, this is where you enter Business Continuity and Disaster Recovery planning – you should have plans in place to cater for these events, if not drop me a line.

And so it is with P1. I said above this is where you light the fire. Though in my experience it’s when you take a deep breath and walk into the MD’s office and let them know the score – as is the way with a solid DR plan. By then you’re well on the way to recovery of course, at least in a planned sense (that’s for another article though).

And I can’t go past talking about password resets. They’re a classic low priority issue, but in fact they’re a P1 for the customer, they can’t do anything until that’s resolved, much the same as a system down in fact. It pays to consider the customer’s perspective as well as the commercial one.

And the final word on the priorities – share them with your customers, communication is key after all.

Clinic

Many would call this second line escalation, but I’ve found it to be more than that. Lumping in some product experts at the front line can do a lot to resolve complex “how to” issues, but there comes a time when the development team, or database admins, or someone who can make a substantial change, is needed.

Clinic is the word I used to describe when the primary role of developers and sys-admins swap from project work to customer-facing tasks. It’s highly effective in both limiting the interruptions on daily work and in closing the gap between back office and front. Remember my comment at the start of this article about every business unit has a customer…

So clinic is a time when the focus is primarily on anything escalated, that can’t be done by the customer or the support team. The outputs of this might be a simple database change, a small patch, or indeed an escalation into the work stack for consideration in a future project.

What this stage does is ensure that the development team is part of the ongoing solution, and get to experience the customer’s journey, sometimes that’s bad but mostly that’s very good indeed!

Data fixes & Patching

As above really, there’s a level of risk introduced in operating in this space, clinic is where a decision on what can be pushed through here is completed. It’s a decision not to be taken lightly and a future article I’m sure.

 Note: The dotted line is where classic project and release management operate. There are many methodologies about this of course, they all include a need to do something, justifying it and getting it done. This is that space.

Workstack

Every request should get a ticket.

There, that’s about all that’s needed to be said… But seriously stuff appearing in your work stack needs to be lodged first. Either it’s come via a customer (P5) or a bunch of customers (Analysis of calls) or indeed it’s come from inside the business, which is just a fancy customer of course!

Why do all work stack things need a support query (ticket)? Well, your contact center will have reporting around who did what and when, who owns it, how long it’s been open and so on. These are all good things to introduce to your development team. It’s nothing new, Jira does this in its software exceptionally well.

Review process

I use principles from DSDM Atern. It has a good model for this using MoSCoW:

• Must have
• Should have
• Could have
• Won’t have at this time

It’s worth a read. If not then use this, it’s the classic high/medium/low in plain English:

• Now – things that are to be worked on now. Resource needs to be found.
• Next – What’s next – put a date on when it’s going to become ‘Now’.
• Never – What’s left on the pile. No ambiguity in calling it “Low”. It’s just not going to get done anytime soon.

There’s more to reviewing of course, but this article is long enough I think!

Projects

You’re far removed from your support team at this point, or at least the context of this article. More on this space as I sip more cherry brandy.

Summary

• Every team has a point of contact – if it’s owning your team, set up a dedicated role at least
• Split your inbound into “information” OR “doing” requests. Handle separately
• If you can, get the people doing support focused on the transfer of information, not just answering the phone
• Get your development team (the folks making changes) involved in support. It breaks silos and encourages a better journey for all
• Everyone gets a ticket

I’d be pleased to share a virtual coffee with anyone who’s finding they’re on the cusp of setting up a contact centre, or indeed want to improve productivity, reporting and integration of an existing team. Drop me a line!

This article is my views based on experiences, training and observations of far too long in the technology arena. Your views, experiences and opinions are yours, valuable and equally pertinent. They’re just not mine and it’s easier to write about the stuff I know!