Running support across two time zones with three people

Three people covering two time zones cannot be online at once, so the desk has to work while nobody is watching. That is a design problem, not an effort problem.

What makes it work

  • A queue, not an inbox. Whoever starts the day opens the queue and sees what is unassigned and urgent, without reading every thread.
  • Handover notes that live in the conversation, not in a chat message that scrolls away.
  • Expectations set on the channel itself: publish the hours, and say what happens outside them.
  • One agreed definition of urgent, or everything becomes urgent at 6pm.

What to avoid

Do not split channels between people ("you take WhatsApp, I take email"). It recreates the silos the shared inbox was meant to remove, and it breaks on the first sick day.

Tags, priorities and views · the complete guide

Free for the first 3 seats. onsitesai.com

Comments

Post a Comment

Popular posts from this blog

The small-team support desk: a complete guide

Image
Most support advice is written for teams with a support manager, a knowledge base owner and a QA process. If your team is three people and one of them is the founder, that advice is a list of things you will not do. This guide is the other list: what a small team actually needs, in the order the decisions arrive, with the trade-off stated rather than hidden. Every section links to a longer piece if you want the detail. 1. Start with one channel, not seven The temptation is to connect everything on day one. The result is an inbox nobody trusts, because nobody has proved that one channel works end to end. Connect the channel your customers already use. Answer one real conversation through it. Only then add the next. Each step should end with a working desk rather than a half-configured one. Free help desk setup, step by step 2. One inbox, or the team answers twice A shared Gmail account works for one person and breaks at three. Everyone sees everything, nobody owns anything, an...
Read more

Handling refunds without a second system

Image
The refund request arrives in a support conversation. Then someone opens the invoice tool, finds the order, calculates the amount, and replies. Three systems, one customer, and a real chance of getting the arithmetic wrong. Why it breaks The conversation does not know which invoice is being discussed. The invoice does not know what was promised in the conversation. Nobody can answer "how much have we refunded this customer this year" without a spreadsheet. Keeping it in one place The conversation should already be attached to the customer record, and the record to the invoice. A refund is then an adjustment on a known order, visible to whoever reads the thread next. That is the reason invoicing sits inside Onsites AI rather than beside it: the conversation, the quote and the invoice share one record, so a refund is not a research project. CRM and invoicing · free CRM setup Free for the first 3 seats. onsitesai.com Related Support metrics that actually change a dec...
Read more

A support policy that fits on one page

Image
Most support policies are written for auditors, not for customers. A one-page version that customers can actually read does more for trust than ten pages nobody opens. Seven lines Channels we answer. Name them, including the ones you do not. Hours, in the customer's time zone where you know it. First response target for each channel — only promise what you hit. What counts as urgent , in one sentence. What we cannot help with , with a pointer to who can. Escalation path when the first answer does not work. Where the record lives , so a customer can ask "what did we agree". Why one page Because the policy has to be quotable in a reply. If an agent cannot paste two lines from it into a conversation, it will not be used, and then it is decoration. Saved replies that still sound human · the complete guide Free for the first 3 seats. onsitesai.com
Read more