Assignment & capacity

Assignment is the difference between a shared inbox that works and one where twelve people watch the same queue and nobody moves. Tola distributes conversations for you, respecting who is available and how much they already have.

Why automate assignment

An unassigned queue has a predictable failure mode: the easy conversations get taken quickly and the hard ones sit there, because picking one up is a decision and nobody wants to make it. Meanwhile two agents open the same thread and one of them wastes the effort.

Automatic assignment makes ownership unambiguous. Every conversation has exactly one person responsible for it, from the moment it arrives.

Assignment policies

An assignment policy defines how conversations distribute. Create one under Settings → Assignment policy and attach it to a channel.

A policy applies per channel, so your WhatsApp queue and your email queue can distribute differently — which is usually what you want, because their pace is different.

Round robin

Conversations go to each available agent in turn. Simple, predictable, and easy to explain.

Round robin works well when conversations take roughly the same amount of effort — a queue of similar product questions, for example. It works badly when they do not, because it counts conversations rather than work. An agent handling one long, complex case gets the same share as one closing quick questions.

Balanced

Balanced assignment accounts for how loaded each agent already is, rather than just whose turn it is. An agent with four open conversations is less likely to receive the next one than an agent with one.

This is the better default for mixed queues, which is most real queues. Use round robin only when you specifically want strict rotation.

Capacity policies

A capacity policy caps how many conversations an agent can hold at once. Set an overall limit per agent, and per-channel limits within it.

Per-channel limits matter because channels are not equivalent. An agent can comfortably hold ten email threads and two live chats at the same time, because email is asynchronous and chat is not. A single number across both produces either an overloaded chat agent or an underused email one.

When an agent is at capacity, assignment skips them until something is resolved. Nothing is lost — it waits, or goes to someone with room.

Team assignment

Conversations can be assigned to a team instead of a person. A workflow routes on whatever you can express as a condition — the channel, a label, a contact attribute, a keyword — and the team's own assignment settings decide who inside it picks it up.

Two-stage routing like this is more robust than routing straight to individuals. When someone leaves, changes role, or goes on holiday, you change the team's membership rather than hunting through rules for their name.

Manual assignment

Automation should not remove the ability to hand something to a person deliberately. Agents can reassign a conversation to a colleague or a team at any point, and can add participants to loop in a specialist without transferring ownership.

Reassignment is recorded in the conversation's activity trail, so a thread that has been passed around three times is visible as such.

Choosing a setup

For most teams, this configuration is a good starting point and rarely needs to change:

1. Balanced assignment on every channel.
2. Capacity limits per channel, roughly: two to three concurrent live chats, six to ten email or WhatsApp threads. Tune after a week of watching.
3. Priority ordering on, so urgent work jumps the queue.
4. Workflows routing to teams by topic, and teams distributing internally.
5. A folder for unassigned conversations, checked by a lead — because the point of a routing system is noticing when it fails.

Then look at the agent report after two weeks. If one person consistently carries more resolved conversations than everyone else, your capacity limits are wrong, not your team.