The right people get the right calls.

Who gets the call.

Being in the team is one half of it. The other half is what each person can handle: everything the team asks for has to be on the person, not just some of it. A caller who pressed 2 for French does not reach somebody who does not speak it, and that holds because the system checks the person, not because the menu was drawn carefully.

Skills are words you invent (french, billing, tier-2), typed onto the person and onto the team. There is no catalogue to pick from and there are no levels. A flat list of words is a thing an office manager can keep true; a competency matrix goes stale in a fortnight and then routes calls with last spring’s answer.

Adding somebody to a team whose skills they lack is allowed, and the row says so as you tick it: it names the skill they are missing. A person who can never be offered a call from a team they are in looks exactly like a routing bug, and the only cheap moment to catch it is while you are still looking at the checkbox.

An empty team says the same thing louder. It reads, in red, that calls sent there will wait for nobody.

Which calls go first is about the calls, not the people. A call to the team you gave your best customers is offered ahead of one that has been waiting longer, which is what you want for that line, and is not the same thing as jumping somebody’s turn at answering.

Only somebody who has made themselves available is offered anything. Somebody who has sent their calls to their own cell phone still is, and a call forwarded to someone’s cell phone keeps hold, transfer and recording rather than becoming a bare forwarded call with none of them.

Choosing who is in a team is a permission of its own, separate from being able to see the teams at all. The reason is written next to it in the code: deciding membership is deciding whose phone rings.

What the caller hears while they wait.

A team can have a menu of its own for the wait: music, roughly how long, or press 1 to be called back, in the order and with the words you choose. It starts over for as long as the caller is waiting, and the one thing it knows is how long they have been there, which is what lets you say the useful thing: once they have waited long enough, offer to call them back.

Alongside those three: a message of your own, a pause, a branch on how long they have waited, and a step that takes them out of the wait entirely.

A callback offer is a promise, so the half that keeps it is a job rather than an intention. It rings the person back, and when they answer they go to the team the way an inbound call does: the same offer, the same fall through to voicemail if nobody takes it, the same buttons once somebody does.

It tries three times and then stops, because a number that never answers is not an outage. It gives up after a day, on the reasoning that the person has moved on and a call out of nowhere tomorrow is worse than no call. It refuses to dial an emergency number back. And one request per call means a retried instruction cannot ring somebody twice.

It counts as kept when the person picks up, not when the network accepted the dial. Those are not the same event, and treating them as one is how a callback that rang out gets recorded as delivered.

A team with no waiting menu of its own plays the standard hold music. That is the default and it stays the behaviour for any team nobody configures, and a waiting menu cannot be attached to a team until it has been published, because a silent fallback at call time is a worse discovery than a refusal now.

Each location keeps its own hours.

Opening hours are not one company-wide setting here. They are named schedules (one per site, or per team, whichever matches how you actually close), each with its own timezone, its own week, and its own dated holidays that can name themselves so a caller hears which one it is. A shift that runs past midnight is a range like any other, not a special case somebody has to remember.

A step in your menu names one schedule and sends the call one of four ways from it: open, a holiday, an emergency, or simply closed. One schedule answers all four, so “are we open” cannot have a different answer on different branches.

And it happens before anybody is asked to answer. A caller at nine in the evening hears your closed message. They do not wait for a team nobody is watching.

A schedule with nothing filled in means open. Every other default would have taken somebody’s phone line down on the day it shipped, silently, as a reward for not having finished setting it up.

The honest edge of that: hours live in the menu, so a number not bound to a menu rings around the clock. It is the design rather than an oversight, but it is also the first thing to check when a line answers at midnight.

One switch for a snow day.

A snow day, a power cut, a flood, a closure nobody could have put in a calendar. There is a switch on the schedule for exactly that, and it is read before the holidays, before the week’s hours, and before the rule that treats an unfilled schedule as open. That last one matters: the business that most needs to say we are closed right now is often the one that never finished filling the hours in.

It is a switch rather than an edit to your hours, on purpose: it must not require publishing a menu at the moment somebody is standing in a stairwell with a phone. It keeps when it went on and who turned it on, and that record outlives the account of whoever did.

It does not take the line dark, either. Every menu using that schedule takes its emergency branch, so what callers hear is still something you wrote: a different message, a different team, straight to voicemail. Switching it off puts everything back, and needs no publish in that direction either.

When nobody answers.

Waiting is bounded. A call is offered for thirty seconds, and if nobody takes it the caller is brought back into your menu on its overflow branch. What happens there is yours: voicemail, a different team, a message and a goodbye.

Nothing is dropped quietly on the way. A published menu that names a team somebody has since deleted sends the call to the catch-all team and records why, because a caller reaching a person who was not the intended person is better than a caller reaching nobody.

And a caller on hold never hears an error. An unpublished waiting menu, a deleted team, a menu that will not load: all of them fall back to hold music, which is what the caller would have heard anyway.

How it works underneath

Every customer’s routing lives in one shared TaskRouter workflow, with one filter per named queue over the same per-customer task queue. The filters are read in order and the first match wins: a call to somebody’s own direct line first, then the named queues, then a catch-all that lands in the fallback queue every company gets, which describes itself: Everyone. Calls that do not name a queue arrive here.

Who may be offered a call is one expression over the person’s own attributes: the queue’s id has to be among their queues, and every skill the queue requires among their skills, so skills are ANDed rather than pooled. An offer lasts thirty seconds; when it lapses the router cancels it and the caller continues on the flow’s overflow branch.

The in-queue flow is served as the wait document of the queue and re-entered from the top on every loop, with no session and nothing carried across passes but the wait so far. The network honours only Play, Say, Pause, Gather, Redirect, Leave and Hangup in that document and silently drops anything else, so publishing checks the blocks against that list rather than letting a caller discover it as thirty seconds of nothing. The in-queue palette is hold music, the wait announcement, the callback offer, a spoken message, a pause, a condition, a variable, and Leave.

Accepting a callback leaves the queue through Leave, which continues at the Redirect placed right after the Enqueue on purpose: without it, the overflow branch would be unreachable by the one route built to reach it, and the call would just end.

A schedule’s timezone is applied at evaluation time, through Intl, rather than stored as an offset, which is the only way nine-to-five stays nine-to-five through March; a range may cross midnight. A queue is written to our own database first and mirrored into the router immediately after; the row is the source of truth, and a lagging mirror is logged loudly and fixed by saving again.

Questions people ask

What happens when everyone is busy?

The caller stops hearing ringing and starts waiting. They get your hold music, then roughly how long, said in words rather than as a count of seconds, then the offer to press 1 and be called back. Pressing 1 takes down the number the call came from, reads it back out loud so they can hear it is right, and lets them put the phone down. Pressing nothing is not a refusal: they keep waiting.

Missed calls while everyone is with a customer

How does a call reach the right person?

By two checks on the person rather than on the call. They have to be in the team your menu chose, and they have to carry everything that team requires: skills are words you invent, such as french or billing, written onto the person and onto the team, and all of them have to be there rather than some. Only somebody who has made themselves available is offered anything, an offer lasts thirty seconds, and the moment it is answered the call is put in a room of its own, which is what makes hold, an introduction before a handover, and adding a third person the same buttons on every call.

What skills-based routing decides, and what it cannot

Can one person be on two teams?

Yes. Membership is written on the person as a list, so somebody can be in Sales and in Support at once and is offered calls from both. Which call reaches them first follows the order you gave the teams, and then how long each caller has waited. Somebody can also be put in a team whose required skills they lack, and the row says so as you tick it, naming the skill that is missing: a person who can never be offered a call from a team they are in looks exactly like a routing fault.

What does the caller hear while they wait?

A team can have a menu of its own for the wait: music, roughly how long, the offer to be called back, a message in your own words, a pause, and a branch on how long they have waited so far. It starts over for as long as they are on the line, and the one thing it knows from one pass to the next is how long they have been there. A team with no waiting menu of its own plays the standard hold music. Nobody is told their place in the line, and when there is no usable estimate the wait announcement says nothing rather than guessing.

What happens when the wait runs out?

A call is offered for thirty seconds. When nobody has taken it the offer is cancelled and the caller is brought back into your menu on its overflow branch, where what happens next is yours: voicemail, another team, a message and a goodbye. Thirty seconds is the figure on every team today. A maximum wait can be typed onto a team and saved, and nothing reads it yet, so thirty seconds is the number to plan around.

What this does not do

This routes calls. It does not run a workforce. Nothing here works out how many people should be on Support at four in the afternoon, nothing measures anybody against a plan they were handed, and no score is kept per person. Queue membership and skills are settings somebody writes because they know the team, not the output of a forecast. And if what you need is the other thing, this is the wrong shape of product rather than a smaller version of it.

The live reading of how many are waiting and how long the longest has waited belongs to the organization as a whole rather than to each named queue, and the figure an announcement quotes is measured the same way. With one queue those are the same number. With three busy ones it is an average across all of them, and a caller in the quiet queue hears the busy queue’s wait.

A maximum wait can be typed onto a queue and saved, and it does not yet decide anything: the thirty-second offer is what ends a wait, on every queue. It is a setting waiting for the code that enforces it, and until that lands the number to plan around is thirty seconds.

There is also no rule you can write for how offers are spread between the people who qualify. Priority orders the calls; it does not take turns among the team, and nothing balances a day’s calls evenly across a queue’s members.

A queue is written to our own database first and mirrored into the router immediately after. If the router is briefly unreachable the queue exists and its routing rule can lag behind it, which is fixed by saving it again and is logged loudly enough that we see it first. Refusing your edit because somebody else’s service was slow for four seconds would be the worse failure.

If one of those is the thing that would actually stop you, say so early. We would rather tell you where it really is than have you find it in week three.