The moment to run a pre mortem (right before you lock the support decision)
You know the moment. The deck is basically done, the staffing model “works,” and someone says, “If we do not decide today, we miss the quarter.” Support operations teams make their biggest mistakes right there, not because they are careless, but because they are already mentally living in the future where the decision went fine.
A pre mortem is your last responsible moment to be pessimistic on purpose. It is not a postmortem, and it is not a therapy circle for anxious operators. It is a short, structured way to ask: “Assume this decision failed in a few weeks. What weak signals would we have seen first, and what would we have done differently before it became expensive?”
That timing matters. Run it after the option set is clear, but before the decision is socially “done.” If you run it too early, it becomes generic risk brainstorming. Too late, and it turns into a permission slip for a plan everybody already sold upstairs.
If you want the classic framing, Harvard Business Review’s piece is still a solid reference: [1]
In support operations, a “weak signal” is a small, early operational symptom that shows the system is drifting, even when headline metrics look stable. It is the quiet uptick in reopen rate in one queue. It is the aging tail getting heavier even though average time to first response looks fine. It is escalation volume staying flat while escalation severity rises.
Weak signals are rarely dramatic. They show up as “huh, that’s odd” moments: a single queue’s transfer rate climbing, a specific region’s late-night backlog getting sticky, or a customer tier suddenly generating more “I already told you this” replies. If you only watch the top-line dashboard, you will miss them until they are loud enough to force a rollback—usually at the worst possible time.
What a pre mortem is not: a hunt for “all risks ever,” a request for perfect reporting, or an excuse to delay. A good pre mortem makes the decision safer to execute, not slower to make.
Support decisions with real blast radius include staffing changes, routing changes, automation expansions, backlog policy shifts, and SLA shifts. The pain often shows up after a few weeks of compounding, which is exactly why loud anecdotes and “looks fine to me” dashboards are so dangerous.
Concrete example: you tighten your first response SLA for email from 24 hours to 12 hours without adding headcount. The first metric that moves is often not SLA attainment. It is agent behavior. Average handle time drops, macros get heavier, and within two weeks reopen rate in the “Billing disputes” queue jumps from 7 percent to 11 percent. The dashboard says you are faster. Customers say you are worse.
This is the decision pre mortem sweet spot: it forces you to admit that systems adapt. Agents adapt. Customers adapt. And automation definitely adapts (usually by confidently doing the wrong thing at scale).
A useful decision pre mortem workflow for support operations produces three things you can actually use during rollout.
First, a signal inventory (your weak signal map) organized by queue and segment. Second, decision rules (your go or no go conditions and stop thresholds). Third, queue level monitoring triggers that clarify what you watch daily versus weekly, and who owns the response.
Practical tip: bring one simple baseline snapshot into the room—four weeks of reopens, aging distribution, escalations, and transfers for the affected queues. You are not trying to build a data warehouse in 30 minutes; you are trying to keep the conversation anchored in “normal” so “drift” is visible.
Practical tip: decide up front what kind of meeting this is. A pre mortem is not an approval meeting. If you mix those two, people posture, defend, and quietly stop telling the truth.
A 30 minute workflow that forces the weak signals onto the table
This is the part teams skip because it feels “soft,” until it saves them from a quarter of cleanup.
Start by flipping the usual order. Do not debate the preferred plan first. Once people start arguing for a plan, confirmation bias shows up like it pays rent. Write the failure story first, then inventory weak signals, then argue about the decision with better information.
The most productive pre mortems have a slightly awkward moment at the start: a little silence, people thinking, and then specific failure stories hitting the table. That awkwardness is a feature. It stops the highest-status voice from setting the narrative before everyone else has a chance to contribute.
Use the table below as a fast way to pressure test assignment and routing choices during the pre mortem. It keeps you honest about what you gain, and what you risk, in plain language.
Instead of “Step 1, Step 2,” think of the flow as a short sequence of constraints that keep the room honest.
Start with the failure story, not the plan story. Pick a short horizon on purpose. Two to four weeks is long enough for leading indicators to emerge and short enough that people can imagine concrete mechanics.
A good failure story names the decision, the customer impact, and the internal symptom. Example: “We expanded automation triage for password reset and login issues. Two weeks later, containment looks great, but high value customers are getting misrouted, reopens spike, and escalation managers are drowning in ‘urgent’ tickets that should have been solved in one touch.”
Once you have a failure story, inventory weak signals by category—but keep it grounded in how support fails in real life: silent backlog, reopens, escalations, latency spikes, and handoffs.
Silent backlog shows up when tickets are technically “touched” but not progressed. Reopens show up when speed wins over correctness. Escalations show up when the system routes ambiguity to humans too late. Latency spikes show up at handoffs, not at the front door.
Practical tip: if your team only watches averages, you are driving by looking at the speedometer and ignoring the fuel gauge.
Then force segmentation, because support systems do not fail evenly. They fail in pockets.
Ask the group to name at least one queue, one channel, one customer tier, one region if it matters, and one time-of-day window where this decision could hurt first. If you cannot name any, you are probably missing the weak signal you are about to ignore.
This is also where tradeoffs become clearer. A routing change that is “fine” for high-volume, low-complexity tickets can be catastrophic for low-volume, high-stakes queues because noise hides the pattern—until a high-value customer is the pattern.
Now comes the part that separates a helpful pre mortem from a doc that quietly dies: converting signals into checks and thresholds that would change your mind.
This is where teams get burned. They write “watch reopens” and call it a day. That is not a plan.
A workable threshold has a segment, a number, and a duration. Example: “If reopen rate in Queue A rises by more than 3 percentage points for three consecutive days after rollout, pause expansion and require human review for that issue type.”
Decision thresholds also need one more thing people forget: a baseline reference. “Reopens went up” is vague. “Reopens are 3 points above the last four-week baseline” is actionable.
Worked example for staffing and routing: you reduce late shift coverage and adjust routing to prioritize chat. Your weak signal is not just missed SLAs. It is an aging tail in email.
Decision threshold: “If more than 15 percent of tickets in the Email Tier 2 queue exceed 72 hours aging at any point during the first two weeks, we revert routing priority and re add one late shift agent until volume normalizes.”
Practical tip: if a segment is low volume, percentage thresholds can whiplash you. In those cases, add a minimum-count rule (“at least 20 tickets in the denominator”) or use absolute counts (“more than 8 tickets older than 72 hours”) so you do not trigger a rollback based on three weird tickets and bad luck.
Finally, make ownership painfully explicit and define what “stop” means.
Pre mortems fail when everybody is responsible, which means nobody is. Assign a single owner per trigger. Also define the stop action in plain language: pause new scope, rollback, narrow eligibility, or add human review.
Common mistake: teams treat thresholds like a performance goal, so they quietly move the line when reality hits. Do the opposite. Treat thresholds like a smoke alarm. If it goes off, you do not negotiate with it.
Another common mistake (and it’s sneakier): using the pre mortem as a political weapon. If the vibe is “let’s generate risks to kill the plan,” people will stop contributing and you will get performative, low-value risks. The pre mortem is supposed to protect execution, not score points.
If you want more background on why pre mortems work as a debiasing move, these are useful reads: [2] and [3]
Do the queue scan that dashboards do not do for you
Aggregate dashboards are comfort food. They taste great and tell you very little about what is happening in the corners.
A queue scan is the antidote. It is not “more metrics.” It is a deliberate look at where pain hides: tails, pockets, and handoffs.
Coverage bias is the first trap. The loudest queue dominates attention because it has more tickets, more Slack complaints, and more visible SLA impact. Meanwhile, a smaller queue quietly degrades until a renewal is at risk.
Mini case: overall time to first response stays stable at 3.2 hours. Leadership relaxes. But in the “API integration” queue, the 90th percentile first response time rises from 10 hours to 18 hours, and the share older than 48 hours grows from 8 percent to 19 percent. Escalations from that queue rise from 4 per week to 11 per week. Aggregation hid it because chat volume increased elsewhere and pulled averages down.
The decision rule here is simple: if you are making a change that affects multiple queues, you do not get to ship based on blended metrics. Your pre mortem should explicitly name which queues are “canaries” where damage will show first.
Practical tip: whenever a dashboard looks “flat,” ask what happened to the 90th percentile and the oldest 50 tickets. The tail is where support trust goes to die.
Channel mix shifts are the second trap. A change in routing or staffing shifts work into a faster channel, and the metrics look better, even if customers are getting worse outcomes.
Concrete example: you push more customers into chat and prioritize chat responses. Chat first response improves, and the overall average time to first response improves too. But chat interactions are shorter, more ambiguous, and more likely to end with “email us if it persists.” Reopen rate on the follow up email queue rises from 6 percent to 10 percent, and escalations increase because the problem was not actually solved.
What people get wrong: they celebrate speed as if speed equals resolution. The fix is to pair speed metrics with quality leakage metrics. Reopens, repeat contact within seven days, and escalation rate are your early truth serum.
A useful scan question: “Where is the work going after the first touch?” If the answer is “somewhere else,” you need a weak signal that measures the cost of that somewhere else (transfers, second contacts, escalations, or aging at the next queue).
Latency and handoffs are the third trap. Routing changes often create hidden handoff time. A ticket bounces from bot to generalist to specialist. Each team “touches” it, so it looks active, but the customer waits.
Concrete weak signal: transfer rate increases by 20 percent in a queue after a routing change, while average handle time decreases. On paper, efficiency improved. In reality, the customer waited longer because progress got chopped into smaller pieces.
This is also why “touch-based” internal metrics can mislead you during change windows. If your pre mortem depends on activity signals, pair them with outcome signals. A queue can look busy and still be failing customers.
Practical tip: add a small qualitative sample to the queue scan during the first week of any major change. Pick 10 reopened tickets and 10 escalations from the affected queues and read them end-to-end. This catches failure modes that metrics cannot name yet (tone changes, repeated misunderstandings, missing context from automation, or customers switching channels to be taken seriously).
If you want a deeper mental model on weak signals as a leadership practice, MIT Sloan has a thoughtful piece that maps well to support ops reality: [4]
Guardrails for automation, so weak signals do not get auto suppressed
Automation is great at doing the same thing every time, which is both the point and the danger. When support operations expands automation triage, it can also automate your blindness. The system quietly suppresses the weird cases that would have taught you something.
Two failure patterns show up constantly.
First, misroutes and wrong categorization. A bot or rules based triage confidently assigns an issue to the wrong queue. The customer waits longer, the specialist team gets surprise work, and your queue level monitoring triggers do not fire because the ticket is sitting in the wrong bucket.
Second, containment that looks good but creates repeat contact. A bot “resolves” an issue by sending a generic article. Customers come back through another channel, often angrier and more urgent. Your containment metric looks great. Your reopen and escalation metrics get noisy.
A useful way to talk about this in a pre mortem is to separate “automation did something” from “customer got a resolution.” Teams get burned when they treat containment as synonymous with success, especially during rollouts.
Guardrails are what keep automation from turning weak signals into invisible signals.
Set one conservative rule that protects learning during rollout: require a human pass when customer tier is high value or regulated, or when the issue type is new, rapidly changing, or historically escalation prone.
Concrete guardrail rule: “All tickets from Enterprise tier that match the new ‘billing adjustment’ intent receive human triage for the first two weeks. After two weeks, automation can handle it only if reopen rate stays within 2 percentage points of baseline and escalations do not increase.”
Also define an exception path that is faster than the normal path. Guardrails are useless if exceptions get stuck.
Common mistake: teams treat exceptions as edge cases and starve them of staffing. Then exceptions become a second backlog with worse morale. Allocate a small, explicit capacity slice for exceptions during the first two weeks, and timebox the policy. You can relax later, but you cannot learn later.
Practical tip: put a “kill switch” decision in writing before rollout. Not a technical switch—an operational one. Who can pause automation expansion the same day? What evidence is sufficient? Which scope gets paused first (segment, channel, or intent)? When you answer this ahead of time, you avoid the slow-motion failure where everyone waits for “one more day of data” while customers pile up.
Practical tip: watch for denominator tricks. If automation changes where tickets land, your dashboards may quietly change what they count. A pre mortem should call out which metrics could be distorted by routing, tagging, deflection flows, or reclassification—because otherwise you will celebrate improvements that are mostly bookkeeping.
If you want another framing of the pre mortem as a stress test for decisions, this reference is useful even if you do not use tooling: [5]
Turn the pre mortem into action, so it does not die in a doc
Most pre mortems fail at the finish line. They produce insight, but not control.
The easiest way to keep it alive is to force the output into the same place decisions are executed. If the plan lives in a rollout doc, the pre mortem outputs should be in that doc. If the plan is managed in a weekly ops review, the weak signals and thresholds should show up as recurring agenda items until the change window closes.
Write the go or no go gate in one paragraph. Keep it readable enough that you would follow it on a bad week.
Example gate for an automation expansion into a new queue.
“We will expand automation triage to Queue B for login issues only if Queue B reopen rate stays within 2 percentage points of its four week baseline for five business days, escalation volume does not increase week over week, and the share of tickets older than 48 hours does not exceed 12 percent. If any threshold is breached, we pause expansion, narrow eligibility to the safest subcategory, and require human review for Enterprise tier until metrics stabilize.”
Notice what makes that gate work: it’s specific, it’s time-bounded, and it has pre-approved actions. That last part is the difference between “monitoring” and “control.”
Then set monitoring cadence that matches how fast the damage can happen.
Daily monitoring is for fast moving weak signals: reopens, aging tail, transfers, and escalations in the affected queues.
Weekly monitoring is for slower signals: repeat contact, CSAT volatility, and whether backlog is shifting between queues.
Assign one owner for daily checks during the first two weeks of change, typically a support ops lead or queue manager. Assign a weekly review owner who can make tradeoffs, often the head of support operations or support director.
One more decision rule that helps: decide which triggers are “investigate” versus “stop.” Not every signal should freeze a rollout, and if everything is a stop signal, people stop trusting the system. A good pre mortem uses a small number of stop thresholds, and a slightly broader set of investigate signals that prompt a quick scan and a concrete explanation.
When a weak signal appears, do not start by explaining it away. Start by limiting blast radius.
Pause when you need time to understand. Rollback when the change is clearly causal and harming customers. Narrow scope when only one segment is failing. Add human review when ambiguity is the problem, especially for high value tiers.
This is also where you protect your team. Without pre-agreed stop actions, frontline leads end up improvising under pressure, then getting second-guessed later. With a pre mortem, the team can say, “We hit the agreed threshold, so we took the agreed action.” That is not bureaucracy. That is operational sanity.
Common mistake: “We’ll just keep an eye on it” becomes the default, and the only real lever left is heroics. If your pre mortem does not specify who looks, what they look at, and what they are allowed to change, you have not actually reduced risk—you have just created a nicer document.
If you want facilitation ideas that keep the room productive without turning it into politics, Workshop Weaver’s guidance is a helpful complement: [6]
A realistic Monday plan:
Calendar a 30 minute pre mortem before your next staffing, routing, automation, backlog policy, or SLA decision. Write one failure story that names the customer harm and the first metric that moves. Pick three weak signals per affected queue, including reopens and an aging tail measure, then attach queue level monitoring triggers with owners. Finally, write one stop threshold with a pre approved action so you do not negotiate with the smoke alarm.
Production bar: if you cannot produce a one page output with thresholds, owners, and stop actions in 30 minutes, the decision is not ready to lock yet. That is not bureaucracy. That is adult supervision for systems that touch customers every day.
| Assignment strategy | Best for | Advantages | Risks | Recommended when |
|---|---|---|---|---|
| weak-signal |
Sources
- hbr.org — hbr.org
- fulcrum.blog — fulcrum.blog
- fs.blog — fs.blog
- sloanreview.mit.edu — sloanreview.mit.edu
- decision-intel.com — decision-intel.com
- workshopweaver.com — workshopweaver.com