When a Launch Date Slips: What the DTV Delay Did to the Call Centre Plan

When a launch date slips, the capacity you built for the old date doesn’t slip with it. You’ve hired, trained and rostered for a day that’s now somewhere else on the calendar, and every week of delay costs you either money or readiness. The US switch from analog to digital television this February is the clearest example I’ve seen of what that looks like at scale. The plan was built for one big day. Congress turned it into two smaller ones, and the call centre had to be re-planned in the middle of the countdown.

I wrote last autumn about intraday staffing, the discipline of re-reading a day while it’s happening. This is the slower cousin of that problem. Nothing’s going wrong at 10:30 in the morning. Instead the whole event moves, weeks out, and you have to decide what to do with the people, the contracts and the training you lined up for a date that no longer exists. I don’t think most teams plan for that at all. They plan for the launch, and treat a slip as somebody else’s problem until it lands on the roster.

What happened to the DTV call centre plan?

The analog shut-off was set for 17 February 2009. In January the FCC hired IBM to run a call centre for the switch, and the $12 million contract was sized for roughly 2 million calls in the transition week and 400,000 on the day itself. That’s a plan built around one date and one national event. Then, in the weeks before the deadline, Congress moved it to 12 June over worries that too many households weren’t ready. Stations were allowed to go early anyway, and 421 full-power stations switched on 17 February, joining about 220 that had already gone. That was roughly a third of the country’s full-power stations.

So the February day happened, just smaller. The FCC’s helpline logged 28,315 calls on 17 February and nearly 49,000 over the two days before it. The day’s count is an undercount, because the switch happened at midnight. Even so, it’s a long way short of the figures the contract was planned around, and it’s exactly what you’d expect when two-thirds of the event gets pushed four months down the road. Nielsen said the day after that 4.4% of US households, more than 5 million, still weren’t ready. Most of the demand hadn’t gone away. It had moved to June.

I don’t know what the FCC or IBM did with the capacity in between, and I’m not going to guess. The public figures are enough. A forecast built for one date is a forecast for that date. Move the date and you don’t have a smaller version of the same plan, you have a different plan. The arrival curve changes shape, the people calling change, and the help they need changes with them. Treating the new date as the old plan with fewer calls is the mistake I’d most want to avoid, because it feels sensible and it’s wrong in every detail that matters.

Why doesn’t a slipped date just shrink the forecast?

I used to think a postponement was good news for the support team. More time to train, more time to test, more time to recruit. It’s only half true. The time is useful, but the event that arrives later is rarely the same event, and the one that arrives early, if any of it does, is a strange partial version you didn’t plan for. The DTV switch shows both. February became a third of the stations and a mix of callers who had prepared too early and couldn’t find their channels, and June became the rest, with the big markets still to come.

There are three things that break when a date moves. The first is volume, because demand splits across two or more dates instead of landing on one, and the split is rarely even. The second is the call mix. People who acted early ask different questions from people who waited, and the February callers mostly needed help running a channel scan on a converter box they’d already bought. The third is your people. Temporary staff hired for a February peak have other plans by June, and training delivered six weeks before a go-live has faded by the time it’s needed. That last one is the one I’d worry about most, because it’s the one nobody puts in the forecast.

If you staff with Erlang C, as I’ve written about with staffing for a product launch, the maths doesn’t change when the date moves. What changes is every input you fed it. Arrivals, handle time, the Tier 1 to Tier 2 split and your shrinkage all need re-reading for each new date. Re-running the old numbers against a new date isn’t a plan. It’s a copy. The fix is cheap: sit down with whoever owns the forecast on the day the slip is announced and re-read each input in turn, asking what the delay has done to it. Most of the answers will take minutes. The one or two that don’t are where the risk is hiding.

What do you do with capacity you’ve already bought?

This is where most of the money goes. When a date slips you’re holding capacity in three forms: people you’ve hired, contracts you’ve signed and training you’ve delivered. Each one needs its own decision, and the worst thing you can do is leave all three running on autopilot until the new date. People you’ve hired can be put to work on the backlog you always say you’ll clear, on testing the scripts and knowledge articles for the launch, or on calling the customers you already know will struggle. A team that’s sitting idle waiting for a date loses its edge faster than you’d think.

Contracts are the second form, and they’re easier to fix before you sign than after. If you’re buying outsourced capacity for a launch, ask what happens if the date moves. Is there a minimum volume? Can the hours move with the date, and at what notice? A contract written around a single day is a bet that the date won’t move, and dates move all the time. Launches slip, regulators change deadlines and suppliers miss shipments. The launch readiness work I wrote about after Heathrow’s Terminal 5 assumed a fixed opening day. A movable date needs the same checklist with a clause about timing added to every line.

Training is the third form and the one people forget. Knowledge decays. If you trained a temporary team in January for a February date and the date moves to June, you’ll need a refresher in late May, and the refresher should be built around what the early callers actually asked. February’s DTV calls were a free rehearsal for June, and the most valuable thing anyone could do with them was write down the top ten questions and rebuild the training around them. A slip hands you real data about the event before the event. Use it. Listen to a sample of the early calls, read the emails, and ask the agents who took them what surprised them. Then change the knowledge articles and the IVR message before the second wave, not after it, so the people calling in June meet answers that were tested on the people who called in February.

How should you re-plan when the launch date slips?

Start by treating the new date as a new event, not a moved one. Re-forecast from scratch: how much of the demand already happened, how much is still to come, and is the remainder bigger or harder than the part that’s gone? For the DTV switch, the June wave included most of the major markets, so the second day was likely to be bigger than the first, not smaller. Then look at who’ll be calling. Early adopters, late movers and people who did nothing at all need different help, and late movers are usually the least prepared and the most anxious. Plan handle time for them, not for the people who called in February.

Next, build a simple date-slip checklist and keep it with the launch plan. It only needs a handful of lines. Who decides whether we stand people down or redeploy them, and by when? What notice does each contract need, and what does it cost to move it? Which training needs a refresher, and who’ll deliver it? What did the early wave tell us, and who’s turning it into scripts? Write the names in. Under pressure, a delay looks like a breather, and teams relax right when they should be re-planning.

Finally, keep the early data honest. A quiet first wave tempts people to cut the plan for the second. Don’t confuse a small first day with a small event. February’s 28,315 calls were a third of the stations and an undercount, not a sign that the whole switch would be easy. The forecast moved with the date. The work didn’t get smaller, it just got later, and later is only an advantage if you use the time.