Initial Setup Checklist for a Multi-Agent Inbox: Assignment, Labels, Quick Replies and Routing Rules

A shared inbox doesn't break down from a lack of features: it breaks down from a lack of agreements. Three people looking at the same chat list without written rules end up answering the same message twice, leaving the customer who wrote at 21:00 without a reply, and arguing over who has to handle whom. This checklist organizes the rollout into four stages —access, assignment, labels and replies, and routing— and it's meant to be checked off, not read straight through. The idea is that you can print it or copy it and that each item has a concrete sign that it was done right.

Before starting, it's worth making a fundamental decision: is the inbox for the whole business or just one team? If there are fewer than five people and a single category of inquiries, almost everything is handled with manual assignment and labels. If there are several teams (sales, support, administration) or several shifts, you'll need routing rules from day one, because informal handoffs via internal chat don't scale.

Stage 1: access and visibility

Before distributing conversations, you have to decide who can see what. An inbox without access control is a privacy problem, not just an organizational one: a customer's data shouldn't be visible to someone who isn't going to handle them.

• Define the named list of people who access the inbox, with name and role. 'The sales folks' isn't enough: if there are no names, no one feels ownership of the inbox.
• Separate at least two levels: those who handle (see and reply to conversations) and those who administer (configure labels, replies, and rules). If everyone is an administrator, any configuration change breaks everyone else's work.
• Review what happens when someone goes on vacation or resigns: the inbox has to keep working without that person. If the answer is 'it doesn't work,' it isn't ready yet.
• Check that each person can log in from the device they actually use. A setup that only works on the office computer is useless for a business with people in the field.

Stage 2: conversation assignment

Assignment is the part that gets improvised the most and the one that creates noise the fastest. There are three basic models, and it's worth choosing one in writing before touching the tool.

Whichever model you use, there are four things that must be settled before opening the inbox to the team.

1. 1Define what 'conversation taken' means. It can mean someone opened it, someone replied to it, or someone explicitly marked it as theirs. Choose one and write it down: if everyone interprets it differently, the pending list is useless.
2. 2Agree on a maximum response time during business hours. It doesn't have to be short, it has to exist and be measurable.
3. 3Define what happens to open conversations when a shift ends. The simplest option: they stay in the inbox with a pending tag and the next shift picks them up.
4. 4Establish who reviews the inbox at the end of the day. A named person, not 'the team'.

Stage 3: tags

Tags are the inbox's filing system. The most common mistake is creating twenty tags on the first day and not using any of them a week later. Better few and used than many and decorative.

• Start with three groups at most: status (new, in progress, waiting on the customer, closed), topic (price inquiry, complaint, after-sales, other) and priority (normal, urgent).
• Set a hard limit: if a tag isn't going to be used at least once a week, don't create it yet. Add it later.
• Define who can create new tags. If anyone can add them, in a month you'll have duplicates with similar names and statistics that mean nothing.
• Write what each tag is for in one sentence. If you can't complete the sentence, the tag is unnecessary.
• Check that status tags are mutually exclusive: a conversation can't be 'in progress' and 'closed' at the same time.

Stage 4: quick replies and templates

Quick replies save time, but poorly written ones do the opposite: the customer receives a text that doesn't answer what they asked. The practical rule is that a quick reply works for the repetitive and predictable, not for what requires looking at the specific case.

• List the five questions that come up most often in a normal week. Those five are the first quick replies; the rest can wait.
• Write each reply in a human tone and with a closing that invites the conversation to continue. A quick reply that sounds like a form makes the customer write again.
• Leave a visible place to personalize: customer name, order number, date. A quick reply with no case data at all is noticeable.
• Separate what is a quick reply (free text the agent can edit before sending) from what is a template subject to approval. They are not the same and they are not managed the same way.
• If you use WhatsApp templates, keep in mind that Meta's approval can take up to 48 hours. Don't leave for the day before a campaign that depends on a new template.
• Check that no quick reply promises timelines, prices or conditions that the business can't sustain. It's the most expensive mistake and the hardest to undo.

Stage 5: routing rules

Routing is not passing the problem to someone else: it's passing the conversation with enough context so that the other person doesn't have to ask again. A poorly built routing rule feels as if the customer started from scratch every time a different person handles them.

1. 1Define the routing reasons in a short list: it's not my area, it's a complaint, it requires authorization, it's a key customer, the topic is sensitive. If there are more than five, they won't be remembered.
2. 2For each reason, write who it is routed to (person or team) and at what hours. A reason without a clear recipient is a conversation that gets left hanging.
3. 3Establish what minimum information travels with the routing: summary of the case, what has already been answered and what is missing. Without that, routing is just forwarding.
4. 4Define what happens if the recipient doesn't respond within a reasonable time. The conversation has to return to the general inbox, not stay in limbo.
5. 5Agree on how the customer is told that someone else will handle them. A brief message prevents the customer from thinking they are being ignored.
6. 6Review the rules once a month and delete the ones that are no longer used. Old rules are what generate wrong routings.

Quick verification table

What to do when something fails

No setup comes out perfect the first week. These are the four most common problems and how to tackle them without beating around the bush.

• Conversations with no reply at the end of the day: it's almost always an assignment problem, not a people problem. Check whether the chosen model has an explicit 'take the conversation' step and whether someone has the task of looking at the inbox at closing time.
• Two people answer the same thing: this happens when there is no written definition of what 'taken' means. Agree on it and communicate it; there's no need to change tools.
• Labels nobody uses: delete them or merge them. An unused label isn't neutral, it dirties the statistics and makes the person who does use it hesitate.
• Transfers that come back unanswered: check whether the recipient has defined hours and whether there is a rule to return to the general inbox. If the problem persists, the rule is probably transferring to a person who doesn't have the decision, only the information.
• Rejected or delayed templates: Meta's approval can take up to 48 hours and there is no way to speed it up. Plan with margin and avoid depending on a new template for a fixed date.

If after reviewing assignment, labels and rules the problem continues, the signal that it's time to escalate to support is concrete: the setup is well defined in writing, the team knows it, and even so conversations get lost or duplicated. At that point it's no longer a problem of internal agreements. Resolution times vary depending on the case and the channel, so it's not a good idea to promise anyone a date before having the diagnosis.

How to know if the setup worked

Two weeks after opening the inbox, do this simple test: take ten random conversations and answer for each one who handled it, what state it's in and why it's in that person's hands. If you can answer all three things for all ten, the setup works. If for more than two you can't, the problem isn't the team: it's that a written rule is missing.

• Come back to this checklist once a month and check the boxes again. Inboxes get messy on their own.
• When a new person joins, the checklist is the onboarding document. If it isn't enough to explain how the inbox works, it's missing detail.
• Save the version you used: comparing how the inbox was set up three months ago with how it is today is the fastest way to see which rules were abandoned.