Reducing a Support Team by 60%: What I Did When Bookings Collapsed

Reducing a support team by 60% is the hardest thing I’ve done as a manager, and the decision itself was the easy part. The numbers made it for me. What I had to get right was everything that came after: who stayed, what the remaining team could still do, and how I’d look the people who stayed in the eye the next morning.

I was running support at AudienceView, a ticketing software company, when live events stopped. On March 12, Broadway’s theatres went dark, and The FADER reported that Live Nation was postponing every tour scheduled for March. For a company whose customers sell tickets to venues, shows and festivals, that isn’t a dip. Bookings fell off a cliff, and the volume of work that follows a booking fell with them. I’ve written about moving a help desk to remote work in a week. This is the other half of that spring, the half that nobody put a checklist together for.

Why did the team have to shrink by 60%?

Because the work it was built for wasn’t coming back on any timeline I could plan around. A support team is sized to volume, and volume at a ticketing company follows bookings. When bookings collapsed, so did the contacts that come with them: set-up questions, on-sale issues, reporting requests. The team I’d been building since 2018, across Toronto, New York, San Francisco and Las Vegas, was suddenly sized for a business that no longer existed.

I’ll be careful here, because the temptation in a story like this is to make it about the manager. It isn’t. Every person on that team was good at their job, and the cut had nothing to do with performance. That’s the point I’d make to anyone facing the same decision. If you find yourself explaining to people why they were chosen, you’ve already lost the conversation, because they weren’t chosen for anything they did. A global event took the work away.

Harvard Business Review’s guidance at the time, published in April by Ken Freeman and republished by Boston University, said layoffs should be a last resort, that you should work hard at alternatives first, and that you should avoid repeated rounds. I’d underline the last one. A team that’s cut in stages spends months waiting for the next announcement, and the ones left behind stop doing any real work.

How do you decide who stays and what the team still does?

Start with the work, not the names. Before you look at a single person, write down what the reduced team has to deliver. That list is shorter than the old one, and it’s shorter than you’ll want it to be. Customers with live events still running. Contractual commitments you can’t drop. Security and access work that doesn’t stop because volume did. Anything else goes on a second list called “not for now.”

Then work out what skills that list needs. In my experience this is where a reduction goes wrong. You keep the people you like or the people with the longest tenure, and find out in the first week that nobody left can do a task you can’t drop. Skills first, then names, with HR and legal in the room from the start. It isn’t comfortable work, and it shouldn’t be quick.

Use the tiered structure you already have. If your support model has Tier 1 doing the repeatable work and Tier 2 and problem management handling the harder cases, a reduction doesn’t need to flatten both evenly. I wrote years ago about the split between the band-aid and the doctor. When volume falls by a lot, the band-aid work shrinks fastest, and the people who can find root causes become relatively more valuable, not less. Check that your decision reflects that, instead of cutting evenly because it feels fair.

What do you say to the people who leave?

The truth, in person where you can, and in plain words. Say what’s happening, why, and that it isn’t about them. Be clear about what the company will do and what happens next. Don’t pad it with softeners, and don’t promise anything you can’t deliver. I’d also spend time on what you can give that costs nothing: a reference, an introduction, a specific description of what they were good at. People remember what you said in that room for the rest of their careers.

Treat the conversation as a piece of work in its own right. Prepare for the questions you can predict, such as benefits, notice, final dates and equipment, and find the answers before you sit down. Nothing is worse than looking at someone who’s just heard the worst news of their year and saying “I’ll have to check on that.” Work with HR to have the answers written down.

And decide in advance how you’ll feel afterwards, because you’ll feel it. I’d do it again with the same information. I’d also be lying if I said it didn’t cost me something. Those two statements are both true, and holding both is part of the job.

What happens to the work and the people who remain?

The first week is about stabilising the service. The reduced team has the same phone number, the same queue and a fraction of the people. Tell customers plainly what’s changed in response times, and use the severity-based prioritisation you already have, so the work that matters most is done first. The tiered service levels matrix I use exists for exactly this: it tells you in advance which promises to protect.

The first month is about the people who stayed. They’re carrying a heavier load and a lot of grief. Some are grateful and some are angry, and many are both at once. They’ve lost colleagues and, in some cases, friends. They also know that if it happened to those people, it could happen to them. A manager who doesn’t name that out loud gets a team that goes quiet and polite and starts looking for other jobs.

Be direct about what you know and don’t know. I told the remaining team what the plan was, that I couldn’t promise there’d be no further changes, and what I’d do to tell them early if that changed. I’d rather someone trust me because I said “I don’t know” than distrust me because I said “it’s fine” and was wrong. I’ll write about keeping a team engaged through that period in a separate piece, because it deserves more room than I can give it here.

Also be honest about the work you’ve stopped. A reduced team can’t do everything it did before, and pretending otherwise burns out the people who remain. Write down what’s paused, tell the people who’d normally ask for it, and give the team permission to say no to anything that isn’t on the protected list. It’s a relief to hear it said by the person in charge.

What would I do differently?

Start the planning earlier, and talk about the possibility sooner. By the time the numbers force a decision, you have no room left to be generous. If I’d modelled the scenarios when the first events were postponed instead of when the bookings stopped, I’d have had a few more weeks to think and a few more options to look at. In any downturn, the useful thing you can do early is work out what a smaller, still-functioning team would look like, so the decision isn’t made under pressure.

I’d also build the knowledge base harder before it was needed. When people leave, what they know leaves with them. The teams that cope best are the ones whose answers are written down, as I described in whether a call centre can help in a pandemic. If your documentation lives in people’s heads, a reduction turns a bad month into a bad year.

One more thing I’d tell anyone in this position: write down your reasoning on the day you make the decision. The criteria you used, the options you rejected and why. In six months, someone will ask whether it could have been done differently, and you’ll want more than a memory to answer with. It also forces you to check that the logic holds when it’s on a page and not in your head.

And plan for the point where the work returns. A reduced team that’s been told “this is permanent” behaves differently from one that’s been told “this is where we are now.” You may not know which it is. Say that. If volume recovers, you’ll need people again, and the way you treated the ones who left will decide whether any of them would come back.

The decision takes a day. The credibility you keep or lose takes the next year.