Shared Inbox for Customer Support: Rules, Routine

A team that answers customers from three places (the site chat, a Telegram account on someone's phone and an email address everyone shares) spends part of every day working out who answered what. Someone replies twice. Someone else assumes a colleague has it. A customer waits a day because the message sat on a phone that was switched off.

A shared inbox for customer support puts all of that in one queue. This guide covers how to set one up and the house rules that keep it working: ownership, double replies, notes, routing, shift handover, and a short daily routine for whoever leads the team.

Shared inbox for customer support: the basics

A shared inbox is one queue the whole team works from. Messages from every channel land in it, each conversation is visible to the people who need it, and each one has a status and at most one owner at a time.

In Hodhod, website chat and Telegram (a company account or a bot) arrive in the same panel, and any conversation can become a ticket with its full history when it needs longer follow-up. Each agent only sees the inboxes they've been added to.

Shared inbox vs shared email or personal Telegram accounts

Small teams usually start with one of two setups, and both break in the same places.

	Shared email address	Personal Telegram accounts	Shared inbox
Who is handling this?	Guessed from reply lines, or asked in a group chat	Only the phone's owner knows	Assignee shown on every conversation
Two people replying	Common	Rare, because nobody else can see it	Visible before it happens
When an agent leaves	Mail stays, the context of who promised what doesn't	History leaves with them	History and notes stay
Response times	Hard to measure	Not measured	Reported per channel and agent

Personal accounts have one more cost: customers end up with an employee's private number, and that employee keeps getting messages on days off.

Ownership: one conversation, one owner

Most of the trouble in a shared inbox comes from unclear ownership, so write the rules down. A version you can copy:

Every conversation has one assignee from the first reply until it's resolved.
If routing hasn't assigned it, whoever sends the first reply takes it.
The owner changes only through reassignment, with a private note saying why and what happens next.
Helping a colleague happens in a private note, never in a reply to the customer.
Before going offline, reassign any conversation that's waiting on you.
During business hours, the lead assigns anything left unassigned for more than ten minutes.

Teams sit one level above this. Billing questions go to the billing team, and inside that team one person owns each conversation.

Avoiding double replies

Two agents answering one customer with two different answers is the most visible sign of a messy inbox. The ownership rule prevents most of it. Hodhod's collision indicator covers the rest: if a teammate is viewing or typing a reply in the same conversation or ticket, you see it. The default mode warns you. You can switch to "block" mode, which still lets you choose "Send anyway". You're also warned if someone replied after you opened the conversation, or if the assignee changed.

Private notes and mentions

Notes are for whatever the next person needs to know: what you checked, what you promised, what you're waiting for. Mention a teammate with @ in a note and they get a notification, which keeps the question next to the conversation instead of in a separate group chat.

A note format that is quick to read:

Checked: payment captured on the 3rd, order not created.

Promised: refund or order by tomorrow 12:00.

Next: waiting for @Sam (billing) to confirm which.

Routing by skill and capacity

With two or three agents, picking conversations by hand is fine. Beyond that the lead turns into a dispatcher. Routing rules do it instead.

In Hodhod you give each agent skills with levels (a language, a topic) and a capacity limit. Rules can look at the inbox, a label, a keyword, the ticket category or business hours, and the strategy can be least-loaded, round-robin or highest skill. When no rule matches, a fallback applies. A decision log shows why each agent was picked, and you can test rules in a simulator before switching them on.

A starter set for a small team:

Conversations in Arabic go to agents with the Arabic skill.
Tickets in the "billing" category go to the billing team, least-loaded first.
Everything else goes round-robin to first-line agents.
Fallback: the team lead.

Capacity is simple arithmetic. Three agents with a limit of four chats each can hold 12 chats at once. The thirteenth customer waits in the queue until someone frees up, which is when a queue position in the widget helps.

Labels vs categories

These get mixed up, so agree on the difference:

Categories belong to tickets, one per ticket: billing, delivery, bug, how-to. You set them in Ticket settings. Five to eight is enough.
Labels go on any conversation, several at once: "vip", "refund", "repeat-contact". Automation rules and reports use them.

Keep a written list of labels with one line on what each means. If agents invent labels as they go, reports stop meaning anything. For priorities on top of this, see ticket triage and prioritization.

Response-time expectations per channel

Customers expect different speeds on different channels. Example targets for a small team, which you should adjust to your own staffing:

Channel	First reply in business hours	Outside business hours
Website chat	2 minutes	Ticket form, answered next morning
Telegram	15 minutes	Answered next morning
Ticket	4 business hours	Clock counts business hours only

Put the targets into SLA policies with "Only during business hours" so deadlines don't run overnight. More on chat speed in live chat response time.

Handover between shifts

Before leaving, the outgoing agent adds a note to each open conversation that is waiting on the team, using the format above. Then they post a short summary for the next shift:

Handover, Tuesday 18:00

Waiting on us: 6, all with notes

Promised: 2 replies before 10:00 tomorrow

Watch: payment gateway errors since 17:30, issue opened, widget notice on

Waiting on customer: 9, nothing to do

Daily checklist for the team lead

Start of day: go through unassigned conversations and the "Unanswered conversations" report. Nothing from yesterday should still be there.
Deadlines: check tickets close to or past their SLA.
Load: look at live load per agent and redistribute if one person is full while another is empty.
Notices: make sure widget announcements are still true, and remove expired ones.
Quality: read five conversations closed today.
End of day: confirm handover notes exist and nothing is assigned to someone who is off tomorrow.

Common mistakes

Everyone watches everything and nobody owns anything.
Conversations stay assigned to people on leave.
Notes turn into long chats. Keep decisions in notes and discussion elsewhere.
One agent keeps a personal Telegram account "for important customers" outside the inbox.
Conversations get resolved to make the queue look short, then reopen the next day.

To see website chat, Telegram and tickets in one inbox with your own team, request a demo. Every plan starts with a 14-day free trial, and the Telegram page explains how that channel connects.

Frequently asked questions

How many agents do you need before a shared inbox is worth it?

Two. As soon as two people answer the same channel, you need to see who owns what.

Can every agent see every conversation?

Not necessarily. In Hodhod each agent sees only the inboxes they've been added to, and conversations can be routed to teams.

What is the difference between a shared inbox and a ticketing system?

The shared inbox is where every conversation lands. A ticket is a conversation that needs follow-up over days, with a priority and a deadline. In Hodhod both live in the same panel.

How do we stop two agents from replying to the same customer?

Start with a clear ownership rule. The collision indicator catches the rest: agents see when a teammate is already viewing or typing in that conversation, and you can switch it from warning to block mode.