The right way to prepare a support team for a scary date is to prepare it for the calls, not the catastrophe. Last Wednesday was 1 April, the day the Conficker worm was due to “activate”, and almost nothing happened. The help desks that came through it well weren’t the ones that braced hardest. They were the ones that had decided in advance what their agents would say, what they’d check and when they’d stop worrying.
That’s a different kind of readiness from the one I wrote about after the Terminal 5 opening. Terminal 5 was a launch you controlled and failed to rehearse. Conficker was a date somebody else set, with a threat nobody could size, and a news cycle that made it sound much bigger than it was. Running a Conficker help desk was the second kind. Most support teams will face both kinds sooner or later. The second kind is harder, because you’re preparing for something you can’t test.
What was supposed to happen on 1 April?
Conficker is a Windows worm that’s been spreading since late last year. Earlier versions checked 250 web domains a day for instructions. The newest variant was set to change that on 1 April, polling a sample of 500 out of 50,000 domains every day, which made it far harder for the security industry to block. Nobody knew what instructions, if any, would be waiting. That uncertainty was the story. By the end of March it was on the evening news, and estimates of infected machines ran anywhere from one million to four million.
On the day itself, The Register summed it up as more hype than havoc. The worm changed how it talked to its controllers, and that was about it. The same piece listed earlier worms with date triggers that fizzled on the day: Michelangelo in 1992, CIH in 1999, SoBig in 2003 and MyDoom in 2004. A coalition of security firms and domain registries, now calling itself the Conficker Working Group, had spent weeks registering and blocking the domains ahead of time. Some of the quiet was luck. Some of it was work done by people most of us will never meet.
The part I’d point a support manager at is the week before. That’s when the calls came. Users who’d heard about it on the radio wanted to know if their PC was infected. Managers wanted to know if they should switch everything off on Tuesday night. And a crop of fake “Conficker removal” tools appeared, registered by people who wanted to sell scared users a cure for a disease they didn’t have. None of that needed the worm to do anything. The fear was enough to fill a queue.
How do you prepare a team for a threat you can’t size?
You split the problem in two. There’s the technical risk, which belongs to the people who patch and monitor, and there’s the contact risk, which belongs to support. They aren’t the same size. On 1 April the technical risk turned out to be small. The contact risk was real for at least a week. A team that only prepared for the first one was ready for the wrong thing.
For the contact side, start with the questions you’ll actually get, not the scenario you’re afraid of. You can write most of them on a whiteboard in ten minutes. Am I infected? How do I check? Is this email about Conficker real? Should I turn my computer off? Do I need to buy something? Each one needs a short, plain answer that every agent gives the same way. If three agents give three answers to the same question, the caller rings back to see which one is true.
Then decide what agents can check without escalating. For Conficker, that meant confirming the Microsoft patch from last October was installed and the antivirus was current. That’s a two-minute check a Tier 1 agent can do, and it answers most callers completely. Write it down as a known-issue entry, the same way you’d handle any recurring problem. I covered the format in my post on known errors and workarounds, and it works just as well for a threat that hasn’t arrived yet.
I used to think the job before a scary date was to imagine the worst case and staff for it. It isn’t. The job is to staff for the questions. The worst case gets its own plan, owned by the people who can actually do something about it.
What should agents say when the news is louder than the risk?
This is where most teams get it wrong in one of two directions. Some play it down so hard they sound dismissive. “It’s nothing, don’t worry about it” lands badly on someone who just watched a news report about millions of infected computers. Others catch the panic and make it worse, telling people to unplug machines or cancel plans. Neither helps. The caller wants to know two things: am I at risk, and what do I do?
Give agents a three-part answer and let them put it in their own words. First, what’s actually known: the worm exists, it spreads through an old Windows hole, and a patch has been out for months. Second, the check: here’s how we’ll confirm your machine is patched and protected. Third, what to ignore: don’t buy any tool that pops up promising to remove it, and don’t open emails that claim to be from us about it unless they come through the usual channel. That third part is the one people forget, and on this occasion it was the most useful thing an agent could say.
Tone matters as much as content. Calm and specific beats calm and vague every time. “Your machine has the March patches and the antivirus updated this morning, so you’re covered for this one” is reassuring because it’s concrete. “You should be fine” isn’t, because it sounds like a guess. Agents who’ve been given the facts can be specific. Agents who’ve been given a memo saying “don’t alarm anyone” will default to vague.
Tell your front line before the news does. If your agents learn about the thing from callers, they’ll sound surprised, and surprise sounds like risk. A ten-minute stand-up on Monday morning with the three-part answer, the check and the list of fake tools does more than any policy document. The Gmail apology last month showed the same thing from the other side: people forgive a problem much faster when the explanation arrives before the rumour.
When do you stand down, and what do you keep?
Decide the stand-down point before the date, not after. Otherwise the team stays on alert for a week because nobody wants to be the one who called it off too early. For something like Conficker, a sensible rule might be: if the call volume on the topic falls back near zero for two working days and the security team has nothing new, we drop the extra briefing and go back to normal rosters. Write it down. Then follow it.
The staffing side is simpler than it looks. The contact spike from a news story is short and front-loaded. It peaks in the days before the date, not on it, and it fades quickly once the news moves on. If you’ve got any flexibility in your rosters, shift it into the week before. I made the same point about weather in my post on snow-day staffing: the demand you can see coming is the demand you can plan for, even when you can’t say exactly how big it’ll be.
What do you keep afterwards? Three things. Keep the known-issue entry, because the worm hasn’t gone away and people will still ask. Keep the list of questions you actually got, because next time there’s a scary date you’ll have a head start. And keep a short note of what the team did that worked and what it wasted time on. That note is the closest thing you’ll get to a rehearsal for the next one.
There’s a temptation, when a feared date passes quietly, to treat the preparation as wasted. I don’t buy that. The preparation was what made the date quiet for your customers. They got clear answers, they didn’t buy a fake tool and they didn’t switch off a server for no reason. That’s a good outcome, even if it doesn’t make a good story.
The worm didn’t need to do anything to test your help desk. The news did that on its own.
Hutch Morzaria is a Director-level CX and Support Leadership professional with 19 years of experience building global support organizations across SaaS, Fintech, and enterprise technology. He has hired dozens of support and CX leaders across his career and holds ITIL Expert certification across V3 and V4.
