Operational Rota & On‑Call Playbook for a 12‑Person Travel Agency (ready‑to‑deploy roster, capacity math & templates)

Most staffing problems in a small agency don't come from being understaffed. They come from nobody being able to point at a document and say "that's the rota, here's who's on call, and here's what happens when it breaks." You end up with a WhatsApp thread, a half-remembered verbal agreement about who covers Fridays, and a senior agent who quietly becomes the escalation point for everything because everyone knows her number.

This is the operational layer underneath the pricing and staffing rework we covered in When Shoulder Season Becomes Year‑Round. That piece was about strategy. This one is about the specific, unglamorous work of turning 12 people into a schedule that holds up on a Tuesday when two flights get cancelled and one agent calls in sick.

Everything below assumes a 12-person agency: a mix of senior advisors, mid-level agents, and one or two juniors, handling email, chat, and phone. The goal is a rota you can deploy this week and an on-call structure that doesn't quietly burn out your best person.

Start with the capacity math, because guessing is where this falls apart

Before you assign a single shift, you need to know how many people you actually need on the floor at a given hour. Most agencies skip this and staff by gut feel, which is why some mornings have four people idle and some afternoons have everyone drowning.

Here's the worked example. Say your busiest weekday window is 11am–2pm, and you're forecasting around 48 contacts in that three-hour block — a mix of phone, chat, and email.

Step 1 — Convert contacts to workload (Erlang-style). Phone is the hard constraint because it's synchronous. Of those 48 contacts, assume roughly 18 are phone calls in the peak hour. With an average handle time (AHT) of about 9 minutes per call:

1. 1
   18 calls × 9 min = 162 minutes of call work per hour
2. 2
   162 ÷ 60 = 2.7 erlangs (raw agent-minutes of call demand)

To hit a reasonable service level (say, 80% of calls answered within 30 seconds) at 2.7 erlangs, an Erlang C calculation lands you at 4 phone-capable agents for that hour. You can't just round 2.7 up to 3 — the queue math punishes you hard once occupancy climbs past roughly 85%.

Step 2 — Add shrinkage. Shrinkage is everything that pulls an agent off live work: breaks, admin, supplier callbacks, training, bathroom, the "quick question" from a colleague. In small agencies this runs higher than people expect — plan for 30–35%, not the 20% the call-center textbooks quote, because your people wear more hats.

1. 1
   4 required agents ÷ (1 − 0.33) = 4 ÷ 0.67 ≈ 6 scheduled to reliably keep 4 live on phones.

Step 3 — Check occupancy. At 4 live agents handling 2.7 erlangs of work, occupancy is 2.7 ÷ 4 = 67%. That's a healthy number to be at. Staff only 3, and occupancy jumps to 90% — that's where quality collapses, calls get rushed, and errors start creeping into bookings.

Sensitivity to AHT — the part people ignore

AHT is the single most volatile input in this whole calculation, and it moves everything. Watch what a one-minute swing does:

A two-minute AHT increase — which is exactly what happens during a disruption event — pushes you from 5 to 8 scheduled people. If your rota has no slack built in for that, disruption days are the days your SLAs break. Build the rota around the 9-minute case, but know your activation triggers for the 11-minute case.

The capacity math flows like this before you ever touch a spreadsheet: [Forecast contacts] → [Phone/chat/email split] → [Erlang C calculation] ↓ [Raw agents needed] → [Apply shrinkage] → [Scheduled headcount] ↓ [Check occupancy %] → [Adjust if >85%] → [Final rota]

Here's a simple diagram of the workflow from forecast to rota.

Use this flow as the order you build your spreadsheet: forecast first, channel split second, then math, then scheduled headcount.

Channel split and concurrency rules

Phone and the asynchronous channels behave completely differently, and treating them the same is a classic mistake. A typical weekday split for an agency looks roughly like:

1. 1
   Email

   ~50% of volume, but tolerant — a 4-hour response SLA is fine

2. 2
   Chat

   ~20%, semi-synchronous, needs a 2-minute first-response

3. 3
   Phone

   ~30%, fully synchronous, the hard constraint

Concurrency is where you get leverage. Set explicit rules so people aren't guessing:

1. 1
   Phone

   1 at a time. No concurrency. A call is a call.

2. 2
   Chat

   up to 2 concurrent for mid/senior agents, 1 for juniors until they're rated up.

3. 3
   Email

   batched. Don't interleave email into live phone/chat time — assign dedicated email blocks (e.g. two 45-minute blocks per agent per day). Email handled "in the gaps" is email handled badly.

Agencies that let people free-float across all three channels simultaneously look efficient on paper and produce the most errors in practice. A booking modified mid-call while two chats are open is how you get the wrong date on a non-refundable fare.

“

Batch email into two fixed blocks per person to protect live-channel focus and reduce costly context switches.

A simple set of channel rules beats clever scheduling where everyone guesses their own limits.

A sample week, hour by hour

Here's a heatmap-style view of coverage for a standard week. Numbers are phone-capable agents live per block (email/chat handled by the same pool, with dedicated email blocks layered on top). Opening hours assumed 8am–7pm Mon–Fri, 9am–3pm Sat.

Notice the Friday morning bump and the lunch dip. Friday mornings skew heavy because weekend-departure clients panic-check their bookings. The lunch dip at 12–13 is deliberate — it's your lowest-demand hour and where you stagger agent breaks so you don't lose coverage at 2pm.

“

Stagger breaks across the lunch dip to preserve the 11–14 peak without extra hires.

The ready-to-deploy CSV roster

agentid,name,role,day,shiftstart,shiftend,channelprimary,breakstart,oncall A01,Senior1,dutylead,Mon,08:00,16:30,phone,12:00,no A02,Senior2,primary,Mon,10:00,18:30,phone,13:30,no A03,Mid1,secondary,Mon,09:00,17:30,chat,12:30,no A04,Mid2,floater,Mon,10:00,18:30,phone,13:00,no A05,Mid3,primary,Mon,08:00,16:30,email,11:30,no A06,Junior1,secondary,Mon,09:00,17:30,chat,13:00,no A07,Senior_3,oncall,Mon,00:00,00:00,phone,,yes

Keep oncall as its own flag so the on-call person is never double-counted as floor coverage. That mistake — counting your on-call lead as a live agent — is how agencies think they have 4 people when they functionally have 3.

SLA handoff acceptance criteria

A handoff that isn't explicitly accepted isn't a handoff — it's a dropped ball with a timestamp. When a case moves between agents or into on-call, the receiving person must confirm these before ownership transfers:

1. 1
   Client + booking reference are stated, not implied
2. 2
   Current state in one line (e.g. "flight cancelled, client rebooked on 14:00, awaiting supplier confirmation")
3. 3
   Next action + deadline is explicit
4. 4
   Money status — any pending payment, refund, or deposit flagged
5. 5
   Receiving agent types "accepted" / says "I've got it" — ownership only transfers on confirmation

If no acceptance happens within 10 minutes of a handoff attempt, it bounces back to the sender and escalates to the duty lead. No silent handoffs.

Overflow: the numbers that trigger action, and the protocol

You need numeric triggers, not vibes. "We're busy" is not a trigger. Here are the thresholds that should activate overflow:

1. 1
   Phone queue > 4 waiting OR longest wait > 90 seconds
2. 2
   Chat first-response > 3 minutes on any live chat
3. 3
   Occupancy on live phone agents > 85% sustained for 10 minutes
4. 4
   Any single agent handling 3+ concurrent chats (over the cap)

Stepwise overflow protocol

1. 1
   Floater activates (0–2 min). The designated floater drops non-live work (email blocks, admin) and joins phone/chat immediately.
2. 2
   Duty lead rebalances (2–5 min). Pull a senior off email blocks; push email response SLA from 4h to 6h temporarily and post that internally so nobody promises 4h.
3. 3
   Chat concurrency relaxes (5 min). Mid/senior agents go from 2 to 3 concurrent chats only with a pinned "high volume, slightly slower today" auto-message.
4. 4
   On-call notified (10 min, if still breaching). On-call agent logs in remotely to take phone overflow.
5. 5
   Duty lead logs the activation with start time, trigger, and which steps fired. This log is what tells you next quarter whether your base staffing is actually wrong.

The insight most agencies miss: overflow that activates more than two or three times a week isn't an overflow problem — it's a baseline understaffing problem wearing a costume. If your floater is activating daily, your heatmap is wrong, not your people.

RACI: who owns what

Role confusion during a busy hour is more expensive than being one person short. Here's the clean split for the five operational roles.

(A = Accountable, R = Responsible, C = Consulted, I = Informed.)

The duty lead rotates — it should not always be the same senior. The fastest way to lose a good senior advisor is to make them the permanent duty lead and the permanent on-call. Rotate both.

Copy-paste templates

Shift-swap request

SHIFT SWAP REQUEST Requested by: [name] Shift to give up: [day] [start]–[end], role: [role] Proposed cover: [name] — has confirmed? [yes/no] Reason (optional): [brief] Channel/skill check: Does cover hold same channel skills? [yes/no] Staffing coordinator approval: [pending/approved] Submitted: [date/time] — must be >48h before shift except emergencies

Formal handover

HANDOVER — [date] [time] From: [name] To: [name] Open cases requiring action:

1. 1
   1. [client / ref] — state — next action — deadline — money status
2. 2
   2. ...

On-call items live tonight: [refs or "none"] Supplier callbacks pending: [supplier / ref / expected-by] Anything the receiver should NOT touch: [notes] Receiver confirmation: "Accepted by [name] at [time]"

On-call incident log

ON-CALL INCIDENT LOG Date/time triggered: Triggered by: [auto-alert / client / agent] Severity: [1 minor / 2 moderate / 3 major] Client + booking ref: Summary: Actions taken (timestamped): [time] - [time] - Escalated to: [name / none] at [time] Resolved at: Follow-up needed next business day: [yes/no — detail]

These templates are ready to copy into your policy document or ticketing tool. Keep the fields as-is so handovers are consistent.

Escalation timeouts and notification rules

The whole point of escalation rules is removing the judgment call at 7pm from a tired junior. Make the timeouts numeric:

1. 1
   Severity 1 (minor, e.g. date-change query)

   on-call handles, no escalation. Log only.

2. 2
   Severity 2 (moderate, e.g. supplier won't confirm a rebook)

   on-call attempts for 20 minutes, then notifies duty lead by phone (not message).

3. 3
   Severity 3 (major, e.g. stranded client, payment failure on a departing booking): immediate call to duty lead. If duty lead doesn't answer within 10 minutes, call the second senior on the chain.

Notification rule that matters: Sev 3 escalations go by phone call, never by message. A Slack message at 7:40pm is not an escalation — it's a hope. Define the chain explicitly:

1. 1
   On-call contacts duty lead directly by phone
2. 2
   If no answer within 10 minutes, call the backup senior
3. 3
   If still no response, escalate to owner/principal

Print this chain with names and numbers on the escalation checklist. A chain that lives only in someone's head breaks the first time that person is the one who's unavailable.

Planned absence, recovery, and not burning people out

On-call rotas quietly destroy small teams because the cost is invisible until someone quits. Set these limits as policy, not favors:

1. 1
   On-call frequency

   no more than 1 week in 4 per person

2. 2
   Post-on-call recovery

   if an agent is called out after 8pm, they start no earlier than 11am the next day — automatically, no negotiation

3. 3
   Comp rule

   on-call standby pays a flat weekly standby amount; actual callouts pay at a premium or bank as time-off-in-lieu, the agent chooses

4. 4
   Planned absence

   holiday requests touching an on-call week must be submitted 3 weeks ahead so the rotation can shift cleanly

5. 5
   Hard cap

   nobody does duty lead and on-call in the same week

The agency that treats on-call as "just answer the phone if it rings, it rarely does" is the agency whose best advisor resents the rota within three months. Comp and recovery rules aren't generosity — they're retention.

A real scenario

A mid-sized leisure agency running 12 staff had no formal on-call rota. One senior advisor had become the de facto escalation point — clients had her mobile, and she was handling roughly 6–8 after-hours issues a week on top of a full floor schedule. During a stretch of weather disruptions, that number spiked and she was fielding calls past 9pm for about two weeks straight.

After putting in a rotating on-call (1-in-4), numeric overflow triggers, and the recovery rule, two things changed fairly quickly. Escalations that used to land on one person got spread across four seniors, and the overflow log surfaced something they hadn't caught before: their Friday 10am–12pm block was structurally understaffed by one agent every single week — the floater was activating every Friday morning like clockwork. They moved one shift, and the Friday chaos basically disappeared.

The retention outcome was the real win. The senior who'd been quietly carrying after-hours stopped looking like a flight risk once her load dropped from 6–8 incidents a week to roughly 1–2 during her on-call weeks only.

When a formal rota like this makes sense (and when it doesn't)

This makes sense when: you're at 8+ people, you offer any after-hours support, and you've had at least one "who was supposed to cover that?" incident. At 12 people you're past the point where informal coverage works.

This is overkill when: you're a 3–4 person agency where everyone already knows everything. Forcing RACI and formal handovers on four people who sit in the same room creates paperwork, not clarity. Keep it lightweight until coordination actually breaks down.

Who should NOT bolt this on as-is: agencies with staff under a collective-bargaining agreement. On-call comp, mandatory recovery windows, and standby pay are often governed by the agreement, and your rota rules can't override it.

Sample language for collective-bargaining-covered teams

> "All on-call assignments, standby compensation, callout premiums, and rest/recovery provisions in this rota are subject to and governed by the applicable collective bargaining agreement. Where any provision of this operational rota conflicts with the CBA, the CBA prevails. Nothing in this document modifies, waives, or supersedes negotiated terms. Questions regarding compensation or scheduling rights should be directed to [HR/union rep contact]."

Run the actual comp and recovery numbers past whoever handles your labour relations before publishing. A rota that quietly breaches standby-pay terms is a grievance waiting to happen.

Pulling it together

A rota isn't the schedule — it's the schedule plus the rules for what happens when the schedule meets reality. The capacity math tells you how many bodies you need at each hour. The overflow triggers tell you the exact moment to react instead of debating it. The RACI and escalation chains remove the judgment call from the worst possible time to be making one. The recovery rules keep the whole thing from eating your best people alive.

Build the base rota from your real AHT and shrinkage numbers, not the textbook ones. Flag your on-call person separately so you never double-count coverage. Rotate duty lead and on-call so no single person becomes the permanent point of failure. Then watch your overflow log for a month — it'll tell you exactly where your base staffing is wrong far more honestly than any forecast will.

Build the base rota from your real AHT and shrinkage numbers, not the textbook ones. Flag your on-call person separately so you never double-count coverage. Rotate duty lead and on-call so no single person becomes the permanent point of failure. Then watch your overflow log for a month — it'll tell you exactly where your base staffing is wrong far more honestly than any forecast will.