Case: support for the summer with two people

Before choosing a structure for a short-staffed month, check whether the work fits at all. Compare load with capacity, both in hours of ticket work.

Capacity comes from a simple rule the team already uses: each coordinator on shift has 30 ticket hours a week (the rest goes to hand-offs, notes, meetings and breaks), and the lead has 8, the target set in January for the lead's own week. A month counts as four weeks. With the lead plus two coordinators on shift in July and August: (2 × 30 + 8) × 4 = 68 × 4 = 272 hours a month.

Keep the assumptions visible. If you quietly raise the coordinators to 35 hours or yourself to 20, the plan fits on paper and breaks in practice: people skip breaks, the lead slides back into the queue. Any extra hours should be an explicit option with a cap and an end date, not a hidden fudge in the capacity line.

A summer forecast starts from last summer, but last summer's raw numbers are a trap when the school has grown. Scale them by the growth you can measure: here, handling hours from June 2026 to June 2027.

The steps: turn last August's handling minutes into hours (16,185 / 60 = 269.75); find the growth factor from the two Junes (20,082 / 17,320 minutes = 1.1595, that is +15.95%); multiply: 269.75 × 1.1595 ≈ 312.77 hours. Against a capacity of 272, August is about 40.77 hours over, roughly 10 a week. July, by the same method, needs 216.34 and fits with 55.66 to spare.

Notice what the unscaled number would have said: 269.75, just under 272. Planned on last year's figures, August would have looked fine. Use hours rather than tickets for the growth too: handling hours grew slightly faster (15.95%) than tickets (15%), because the mix shifted toward longer tickets.

Total hours tell you whether the month fits; the mix tells you where the hours go. August grows mostly because of one subject: payment, refund and package tickets rose from 200 in July 2026 to 390 in August, as families buy before the September restart.

To see their weight, take the share of handling minutes, not of tickets. In August 2026, payments and refunds took 3,230 chat minutes plus 3,000 email minutes, 6,230 of 16,185 in total: 38.49% of the minutes from only 22.52% of the tickets. A payment ticket takes about 36.7 minutes; a scheduling ticket about 12.8. Scheduling is the mirror image: 28.48% of tickets, 16.96% of minutes.

This changes the plan. Saving minutes on long tickets (a clear help page, better drafts) is worth more than speeding up short ones, and the long, sensitive payment tickets deserve one consistent owner each day.

A ticket count treats a two-minute password question and a forty-minute refund dispute as the same unit of work. For planning people's time, that's misleading. Plan in hours of handling, and use ticket counts only to explain where those hours come from.

The August mix shows why. Payments and refunds were 22.52% of tickets but 38.49% of handling minutes; scheduling was 28.48% of tickets and only 16.96% of minutes. A plan built on ticket shares would give scheduling more attention than payments, the reverse of where the time goes.

Two practical consequences. First, savings: a clear payment-and-package help page, built with the product team before mid-August, and AI drafts for scheduling and package questions (refund replies still written by hand) cut minutes where minutes are. Second, structure: long, sensitive tickets go better with one consistent owner each day than scattered across whoever is free. Don't push them to another team; that only adds a hand-off for every family.

Apply the three team shapes from the previous lesson to the August facts, and two of them fail at once. By channel: chat brings 64.9% of tickets, so a chat person and an email person would be lopsided, and one family's payment story would bounce between them. By subject: with two people and rotating vacations, a payments specialist is gone half the month.

What works is a shared pool with named rotating roles. Both people take the queue, so neither sits idle whatever the mix. Each day one of the two is the payments owner: the long, sensitive tickets get one consistent hand, and while Olha is on vacation that owner decides refund exceptions inside the policy up to a limit Olha sets, with Iryna's OK; anything above goes to Iryna. The lead takes the morning email catch-up, which absorbs the after-hours backlog (25.15% of last summer's tickets arrived outside 09:00–18:00).

A pool with no named roles fails too: refund decisions would be left to chance.

A gap of about 40.77 hours, roughly 10 a week, rarely has one answer. As with the September decision earlier this month, put several real options on the page, each with its cost:

• More lead ticket hours, a set number, for four weeks, with an end date: from 8 to about 18 a week. It's a risk to name (it's how January went), not a ban: in January there was no cap and no end.
• Stagger the last vacation weeks so three people are on shift, but only if the people themselves agree.
• Temporary help for the last weeks of August: it costs money, so it's Iryna's call, with Hanna on the budget.
• Cut minutes on long tickets: a payment-and-package help page with the product team before mid-August, AI drafts for scheduling and package questions, refund replies written by hand.

Two things are not options: a month of overtime for the two on shift, and cancelling anyone's vacation. Both break the team's must-haves.

Decision rights, from the first lesson of this month, sort the August plan into two piles.

The lead decides, after consulting the two on shift and Olha: the team's own way of working. The pool, the daily payments-owner rotation, who takes the morning email, the order of the shift checklist. These are reversible, so run them as a trial: from Monday 2 August, review on the 16th, recorded in the decision log.

Iryna approves anything above the team: temporary help, because it costs money (Hanna agrees on the budget); the limit up to which the coordinator on shift decides refund exceptions while Olha is away, since Iryna decides everything outside the policy and agrees changes to who decides; and any change to the refund policy itself.

Saying this clearly in the plan saves a round trip. Iryna sees at a glance what she's asked to approve, and the team knows which parts are already decided and which still wait for a yes.

The pre-mortem from earlier this month works the same way for the August plan: "It's 31 August and the month went badly. Why?" The key is who writes. The people on shift see risks the lead can't, so each of the three (the two on shift and Olha) writes reasons alone first, and the lead shares their own list last, so nobody anchors on it.

Olha's guess shows why: on a Monday morning, the payments owner was also the only one on chat. The lead hadn't seen that clash. Turned into a check, it's specific and cheap: the payments owner never covers the morning chat alone.

Add triggers with actions: first replies over 45 minutes two days running, and the lead joins the queue that day and asks Iryna to start the temporary help; someone on shift goes a week without a full day off, and the lead covers.

How it fits together: capacity and the scaled forecast size the gap, the mix shows where it is, the structure, options and decision rights close it, and the pre-mortem protects it. Next month turns to people: coaching, fair evaluations and a team that runs without you.