Prepare for a busy period
Check the allowance against the volume you expect, decide which channels are trusted to answer without a person, confirm the phone lines and their capacity, and name who works the queue each day. A spent allowance holds work rather than dropping it, so the failure of an unprepared peak is a backlog nobody planned for rather than lost mail.
The allowance, and what running out actually does#
The daily allowance bounds how much mail is processed. When it is spent, work is held rather than dropped, and the read cursor deliberately does not advance — advancing it on a refusal is precisely how a mail agent loses messages permanently. The refusal shows in the queue a person works.
So the risk of an under-provisioned peak is not disappearance, it is delay: a Monday of held work that someone must still get through on Tuesday, on top of Tuesday. Estimate the volume, compare it with the allowance, and if the numbers do not meet, change the plan before the peak rather than during it. The operator's own workspace has no plan and no gates; a customer workspace is bounded by its plan's allowances, and that is the only difference between the two audiences.
Decide autonomy per channel, deliberately#
A peak is when the cost of ask_before_send is highest, because every held reply is a reply the customer has not received and a decision somebody must make while busy. It is also when the cost of a mistake is highest. The useful move is not to pick one setting for everything but to split by risk.
| Traffic | Mode | Why |
|---|---|---|
| Routine enquiries on a well-grounded topic | autonomous | Knowledge covers it, and holding these is what creates the backlog |
| Anything commercial | ask_before_send | A price or a term that Knowledge does not support is refused anyway; a person should see the escalation quickly |
| Your few most important accounts | ask_before_send at the contact scope | Narrowest wins, so this costs nothing elsewhere |
| A channel you have not tested under load | draft_only for a day first | It writes and stops, so you can read what it would have said with nothing at stake |
The phone needs its own pass#
Check each line's hours and confirm the closed-line message is right, because a peak week is when out-of-hours calls arrive.
Result Callers outside hours hear something deliberate in your business's name and the call is recorded with an after-hours outcome.
Look at line health before the peak rather than during it. It names four things: a voice worker that has not checked in, a fleet with no capacity left, a run of calls that never rang, and sessions the model refused.
Result Each entry drains by itself as its cause clears, so an empty list is a real all-clear rather than an unread one.
Understand what happens at capacity. A call is refused as not-ready when every live worker is over its load ceiling, which lets the attempt be retried rather than failing a caller silently.
Result You know that busy shows up as retries and refusals, not as calls that vanish.
Check what is already scheduled. Phone follow-ups drain a couple at a time on each engine tick, and a row more than a day late is closed as missed rather than rung.
Result You will not be surprised by a queue of call-backs that quietly expired while everyone was busy.
Staff the queue, and check it was staffed#
The single most reliable failure of a busy week is that everything worked and nobody looked. The queue is ranked rather than chronological, which helps, but a ranked queue nobody opens is still a queue nobody opens. Name a person per day rather than assuming the team; a held reply to a first-time enquiry is a different kind of debt from a held reply on a thread that has been running a week, and only a human decides which to do first.
- Volume was fine, replies were slow
- The channel was on
ask_before_sendand the queue was under-staffed. The customer experienced silence, not patience. - Work stopped mid-morning
- The allowance was spent. Nothing was lost and the cursor did not advance; the refusal was in the queue.
- Calls did not connect at the peak hour
- Capacity. Refusals are recorded as such, and line health names the cause.
- Follow-ups were made a day late or not at all
- The very late ones are closed as missed by design, on the view that a call-back long after it was promised is worse than none.
- Nobody can say what happened
- The decision log can: what was decided, by what, under which rule, and what happened, refusals included. Read it in the review rather than reconstructing the week from memory.
Questions#
Should I turn autonomy up for a busy week?
Only where Knowledge genuinely covers the traffic. Turning it up on a channel you have not read the output of is trading a backlog for a set of replies you will spend the following week apologising for.
What happens if the allowance runs out overnight?
Work is held and the read cursor does not advance, so nothing is skipped. In the morning you have a backlog and a refusal in the queue, not a gap in the record.
Can I raise the allowance temporarily?
Allowances come from the plan, so this is a commercial change rather than a setting. Decide it before the peak — mid-peak is the worst moment to be reading about plans.
Is there anything worth turning off?
Outreach, usually. Cold sequences compete for the same allowance and the same attention as customers who are actually writing to you, and they are the one kind of work that can be paused with nobody waiting on the other end.