The lever menu nobody wrote down
Fast decisions need a short menu
Real-time decisions need to be fast, and fast decisions are easier when the menu is short and pre-written. Operations that haven’t named their levers find that real-time decisions get invented under pressure, look inconsistent across analysts and shifts, and quietly degrade over time as the team learns the wrong patterns. The fix isn’t complicated: write down the five or six levers the real-time function has, the conditions under which each fires, the cost, and who authorises it. The menu fits on one page. Most operations don’t have it.
The five or six levers every operation should have
1. Overtime offer. The most common lever. Pre-agreed rate, pre-agreed cap per agent per week, pre-agreed authorisation. The agents who volunteer are tracked so the same people don’t carry the load disproportionately.
2. Early release. The lever for the opposite problem — over-staffed against a quieter-than-forecast day. Agents who volunteer go home early with paid hours preserved (or unpaid, depending on contract). Saves the cost of un-utilised time without dispute.
3. Training defer. The pre-agreed rule for moving planned training out of the day when SL is under pressure. The deferral cost is tracked because chronic deferral creates a training-pipeline problem.
4. Skill flex. The pre-agreed routing change that opens secondary skills when primary skill is over-running. Only useful in operations that actually have multi-skill agents who can deliver the secondary work; see the multi-skill illusion.
5. Outbound switch-off. For operations that do both, the rule for pausing outbound to release agents into inbound. The cost is the outbound campaign loss; the calculation is whether it’s worth it against the inbound recovery.
6. Outsource burst. The biggest lever. A pre-agreed relationship with an outsourcer that can pick up overflow at short notice. Expensive per contact, valuable in a real crisis, requires pre-existing contractual relationship to be useful.
What each lever needs documented
Four fields per lever turn an abstract option into a fast decision.
Trigger condition. The specific, numerical condition under which the lever fires. “SL trending below 75% over 90 minutes” rather than “when things get bad.” The trigger condition is the rule the analyst doesn’t have to reinvent under pressure.
Cost. The financial cost (or saving) of pulling the lever. Used to compare options when more than one fires at once, and to justify the choice after the fact.
Authorisation. Who can pull the lever without further approval, who needs a TL sign-off, who needs operations leadership. The authorisation is what makes the lever actually fast — the analyst who has to chase a senior decision-maker can’t move quickly.
Communication plan. Who needs to know that the lever has been pulled, in what format, how quickly. Often missed; consistently expensive when missed.
Building the menu collaboratively
The lever menu can’t be written by the real-time team alone. The cost numbers need finance, the authorisation rules need operations leadership, the trigger conditions need calibrating against historical data, and the communication plan needs aligning with TLs. Operations that build the menu in a single workshop with all those functions in the room find it produces faster decisions and fewer post-event disputes about whether the analyst should have acted.
The workshop is half a day. The output is a one-page menu. The maintenance is a quarterly review to update cost numbers and trigger thresholds as the operation changes. The investment pays back in clearer decisions and faster execution within weeks.
What the menu protects against
Three failure modes that disappear when the menu exists.
The expensive default. Without a menu, real-time decisions drift toward whatever’s easiest to authorise — usually overtime. Overtime is the most expensive lever per recovered SL point on most operations, and the one that creates the most agent-burnout side-effect. A menu forces the analyst to consider the cheaper options first.
The inconsistency between analysts. Without a menu, different analysts make different calls in the same situation. Operations leadership sees the inconsistency and starts second-guessing the function. A menu produces predictable, defensible decisions that build the function’s authority over time.
The post-event blame game. Without a menu, every intervention gets second-guessed after the fact. With a menu, the question is whether the trigger condition was met, not whether the analyst should have acted. The conversation gets cleaner and the function gets protected.
Conclusion
The lever menu is one of the cheapest disciplines a real-time function can adopt and one of the most consistently neglected. The work is half a day to write, an hour a quarter to maintain. The payoff is faster decisions, more consistent calls across analysts and shifts, lower cost per recovered SL point, and a defensible operating model when something is questioned after the fact. The menu doesn’t replace judgement — it makes the judgement happen in advance, when the analyst has time to think clearly, rather than in the moment when they don’t.
Next in the series: Communicating real-time to the rest of the operation.
Pair this with real-time playbooks, the cost of perfect adherence, and hiring a real-time manager.