Building a Three-to-Five-Year Support Plan

A three-to-five-year support plan has to answer one question honestly: what does this team need to be able to do in three years that it can’t do today? Everything else, the tools, the hires, the reorganisation, follows from the answer. I spent my first five months at Q4 working out mine, and I want to show how I built it.

I’d done this kind of planning twice before. At AudienceView I took a support operation from a P2 response time of more than 20 days to a two-day target, and at Tyco I built a structure for four regional contact centres. What I’d learned both times is that the plan isn’t a document. It’s a sequence of decisions in the right order, each one making the next possible. The most common mistake is to buy a tool before the structure exists to use it.

After learning the industry and understanding the quarterly cycle, I had enough to write it down.

How do you start a multi-year plan for a support team?

With three honest lists. What’s working and should be protected. What’s failing customers right now. And what’s missing entirely. The first list matters more than people expect. A new director who treats everything as broken loses the goodwill of the team before the plan has started. Most teams have something they do well, and a plan that builds on it is easier to deliver and easier to believe.

The second list should be tied to evidence. For us, the clearest item was the initial response time of around 17 hours, in a business where customers work to hard deadlines. The third list, what was missing, was longer. We lacked defined roles for the levels of support, a dedicated training function, a structured way to check quality, a rounded view of how individuals and the team were performing and a consistent way to hear from customers.

Then I asked a different question: what would the team look like if it were excellent? Not perfect. Excellent in the specific ways our customers would notice. Fast first responses. Right answers the first time. A technical team that understands the customer’s deadlines. People who stay long enough to get good. That became the destination, and everything on the lists was measured against it.

What went into the plan?

Six pillars, in an order that mattered. I’ll give each one a short summary here and then write a post on each, because they deserve more room.

The first was structure: clearly defined Tier 1, Tier 2 and Tier 3 roles, with an explicit description of what each handles, when to escalate and how a person moves up. This is the foundation, because every other piece depends on knowing who should be doing what. It’s the same split I described in what a help desk is, applied to front-end technical support.

The second was location. A team distributed across North America and Europe already covered a good part of the day. I wanted to extend that into Latin America, with a nearshore team in Mexico working in a similar time zone to our North American customers. I’ll cover that in a separate post.

The third was channels and routing. How requests arrive, by phone, email and chat, and how they get to the right person, decides how quickly a customer hears from us. The plan called for skill-based routing, omnichannel case distribution and automatic prioritisation and categorisation, so a request would reach a person who could handle it without being sorted by hand first.

The fourth was people capability: dedicated training and QA teams. A routing system only helps if the person at the end of it is good at the work, and a team can’t be consistently good without someone responsible for teaching and checking. I’d built this at AudienceView, as described in the AudienceView University case study, and it was the most reliable investment I’d ever made.

The fifth was measurement and the customer’s voice: employee scorecards that gave a rounded view of performance, and a Voice of Customer programme combining CSAT and NPS. I’d argued in my piece on why a company needs a tech support scorecard that a scorecard should change behaviour, not just report it, and I intended to build one that did.

The sixth was automation and AI. Manual classification of incoming tickets was taking a large amount of skilled people’s time, and the technology to automate it had matured enough to be worth a serious look. It sat last in the plan on purpose, because AI works best on top of a clean structure and clean data. Put it first and you automate a mess.

Why does the order matter?

Because each piece depends on the one before it. You can’t route by skill until you’ve defined the skills. You can’t train toward a standard until you’ve defined it. You can’t build a scorecard before you know what the roles are. You can’t automate triage until the categories are clean and consistent. The temptation in a new job is to start with the exciting item, usually the technology, and then discover it doesn’t work without the unglamorous groundwork underneath.

It also helps with change management. Spreading the changes over years means the team only has to absorb a few at a time. A support team that’s asked to change structure, location, tools and measurement all in the same quarter will, understandably, push back. Staged changes give people time to see each one work before the next arrives. And success in the early pieces earns the credibility needed to ask for the later ones.

Build in checkpoints. For each pillar, write down what you expect to see and when, so you can be honest with yourself and with leadership if it isn’t happening. A plan without a way to tell it’s failing is a wish. Response time was my main measure, because it was what customers felt most directly, and it was the number I wanted to see move first.

How do you get agreement for a plan that takes years?

By connecting each pillar to something leadership already cares about. Nobody senior gets excited about a skills matrix. They do care about renewals, about the customers who escalate to the executive team and about what support costs relative to the revenue it protects. Write the plan in those terms: here’s the problem, here’s what it costs us in customer confidence, here’s the investment and here’s how we’ll know it worked.

Show them the cost of doing nothing, too. A 17-hour first response in a business with hard customer deadlines was a risk with a name. Putting that on the table, with real numbers, changed the conversation from “why do you need more” to “what happens if we don’t.”

And share the plan with the team before it’s final. They know the work better than you do, and their suggestions will change it. More importantly, a plan the team has helped shape is one they’ll defend when it gets difficult.

The plan isn’t finished, and I wouldn’t want it to be. I’ll revise it every quarter, as the peaks teach me things. But it gives the team a direction and gives me a way to say no to the things that don’t fit.

A last point on planning itself: write down what you’re choosing not to do. Every plan has a list of good ideas that didn’t make the cut, and that list protects you. When a good idea turns up in month eight, you can look at the list, see why it was left out and decide whether the reasons have changed. Without it, you reopen the same arguments every quarter and the team never knows what’s actually committed.

Review the plan on a fixed rhythm. I look at it every quarter, after the earnings peak, when the team has the most evidence about what worked and the least pressure. It’s the right moment to move an item earlier, push another back or drop one entirely. A plan that never changes was never really tested, and one that changes every week isn’t a plan. Quarterly revision sits between the two.

And be generous with the credit. A multi-year plan only succeeds if the people doing the daily work believe in it. Name the people who contribute ideas, describe what each pillar means for them personally, and recognise progress as it happens, not only at the end. People will carry a long plan for a leader who keeps showing them it’s working.

A plan is a promise about the order of things. Get the order right and the rest is work.