Enabling Chat for Users
Chat is granted to groups, so enabling it is a permissions decision like any other.
Where to find it
Architect Panel → Communication:
- Manage Chat Engines — the engines being offered
Architect Panel → Security:
- Permissions — the groups chat is granted to
Security groups themselves are managed in the Admin Panel sidebar under User Administration → User Groups; what a group may reach is granted in the Architect Panel.
It is an operational commitment
The thing to understand before switching it on for customers. Chat implies somebody is there — that is what the interface communicates, whatever your wording says.
A chat channel with nobody watching generates messages that go unanswered, and an unanswered chat message reads as being ignored in a way an unanswered e-mail does not. It damages the relationship rather than merely failing to help.
Set expectations honestly
If chat is staffed between certain hours, say so in the interface — not in a policy document. If responses take hours rather than minutes, say that too.
People will accept almost any stated expectation and will not accept an unstated one being missed.
Decide what happens outside hours
Either close the channel or say clearly when somebody will respond. Leaving it open and silent is the worst option, and it is the default if nobody decides.
Start internally
Enable for staff first. It surfaces the practical questions — notification behaviour, how conversations are found later, what happens when somebody is away — at no cost, before customers are involved.
Roll out to one group at a time
Rather than everybody at once. Volume is hard to predict, and a channel that turns out to be popular is much easier to staff if it arrived gradually.
Watch what people use it for
Chat attracts questions that should be tickets, and requests that need a record. If the same question arrives repeatedly, that is a documentation gap; if substantive requests arrive, they need routing into a process rather than answering in a conversation nobody can find later.
Train the habit of recording outcomes
Anything decided or agreed goes onto the record's timeline. Without that habit, a year of chat history contains the answers and the records do not — and nobody reads chat history to understand a case.
Worked example
An organisation enabled chat internally for two months before offering it to customers, then to one customer segment at a time. The interface states staffed hours and a response target. Handlers write outcomes to the case timeline, so the case still explains itself to somebody who was not in the conversation.
Recommendations
- Do not open a channel nobody is watching.
- State hours and response times in the interface.
- Start internally, then one group at a time.
- Record outcomes on the record.