Customer service

A Business-Gym service desk is shared-mailbox triage with a person on the send button. Customer mail arrives in mailboxes you already have, gets classified and routed to the Head that owns each one, and comes back to you as a draft reply you read before it leaves.

Nothing here sends by itself. That is the whole shape of the product today, and this page shows what it looks like for a two-person desk at a German SME with a handful of service addresses.

What does a service desk look like in Business-Gym?

It is a small set of shared mailboxes, each bound to exactly one owner Head, all feeding the same triage queue that your two service people work through.

You set the bindings on the Channels page, under Build in the sidebar. A typical Muster-GmbH setup binds service@ and info@ to the customer-service Head, rechnung@ to Accounting and jobs@ to HR, so an invoice question and an application never land in the same pile. Each mailbox row also carries an autonomy mode: new mailboxes are created Read-only (triage and digest only), and most service desks move theirs to Draft & stage once the routing looks right.

The customer-service Head ships switched on for every workspace under the title CCO. Its charter is written to draft and propose resolutions, escalate what it cannot answer, and hold no spend authority at all — goodwill credits escalate to a person. See working with a Head for how to read and edit a charter.

How does a customer email become a reply?

The item is ingested, classified, routed and matched to a known contact before anyone looks at it, and then a person decides what happens to it.

On the Inbound page you get an Overnight digest line per mailbox — something like “7 in service@ overnight — 2 hot, 1 needs you, 4 routine” — above the Triage queue itself. The queue defaults to the Needs action status filter, and you can narrow it by intent: complaint, support_question, invoice, quote_request and the rest of the classifier’s vocabulary.

Each row shows what the Head suggests and offers the verbs:

• Draft reply — composes a reply and opens it inline for you to read and edit.
• Create task — turns the item into work for a Head instead of an answer.
• Forward — hands the whole thread to a colleague or Head to own.
• File — keeps it in the Head’s knowledge with no reply and no task.
• Dismiss — marks it handled and drops it out of the active queue.

The draft is grounded in your own material — your company profile and knowledge base are retrieved and prepended before the model writes anything, along with any per-channel handling instruction you have set. When you are happy with the text you click Send reply; Discard rejects the draft and puts the row back in play. That Send is the same approve-and-send path you would take from the approval queue — it is one human decision either way, and there is no code path that skips it.

Caution

Sending is also held behind a verified-sender go-live switch an administrator turns on per workspace. Until it is flipped, approving a reply records your decision but no mail leaves. If a reply you approved has not arrived, check that switch before you re-read the draft — see email and channels.

What does a two-person service day actually look like?

Two people can run this as a morning pass and an afternoon pass, with the queue as the shared handover rather than a spreadsheet or a standup.

1. Morning, first pass. Open Inbound, read the Overnight digest per mailbox, then filter the queue to complaint and legal first. Those are the items the digest counts as needs you, and they are the ones that get worse while they wait.
2. Morning, main pass. Work support_question and quote_request one Head at a time rather than top to bottom. Draft reply, read it against what the customer actually asked, edit rather than rewrite, Send reply. Correct the intent chip on anything that was classified wrong before you move on.
3. Midday handover. Nothing needs to be written down. The second person opens the same queue on Needs action and sees exactly what is left; anything already handled has moved to the History tab as done, dismissed or awaiting approval.
4. Afternoon, second pass. Clear what came in over lunch, then switch the status filter to check that nothing you staged earlier is still sitting unapproved.
5. End of day. Every remaining row should have a named reason for being there — waiting on a colleague, waiting on a connector, or genuinely undecidable today.

Tip

Correcting the intent chip costs a second and is the highest-value thing either of you does. A wrong category produces a wrong draft no matter how well written it is, so fix the category before you judge the wording. The rhythm is covered in more depth in the inbound triage cockpit.

Which channels can the desk actually cover today?

Email carries the real service volume, and the social channels are inbound-only, so plan the desk around mail and treat the rest as a reading surface.

• Microsoft 365 shared mailboxes — live, and the channel the desk is built around.
• Instagram and Facebook — live for inbound only. Comments and conversations are pulled in, classified and routed like any other item, but there is no reply path: you triage the item here and answer it in Meta’s own tools.
• LinkedIn — live through a desktop operator on a PC you control, which is useful for partner and recruiter traffic but rarely where customer service happens.
• WhatsApp, Telegram, Slack, Microsoft Teams, phone, web forms and reviews — not available yet.

The last line matters for a service desk more than for any other department, because it is exactly where customers try to reach you. The adapters exist and the Connect a channel picker will hand you a webhook URL and a signing secret, but no messages flow through them. Do not migrate a working WhatsApp support workflow onto the strength of that picker.

What is the desk never allowed to decide?

Anything that costs money or leaves your company waits for a person, and no amount of confidence changes that.

Refunds, credits, commitments and every external send require a human approval. The customer-service Head’s charter states it as a standing instruction, and the platform enforces it below that as the hard floor — a rule that does not move at any autonomy setting.

It answers from your knowledge base or escalates. The Head is instructed never to promise timelines, refunds or legal terms without approval, and never to invent a policy or a fact. A question your knowledge base does not cover should come back to you as an escalation rather than a confident guess.

A suspicious message is fenced, not obeyed. An inbound item that looks like a prompt-injection attempt gets an Injection risk pill in the queue with a note telling you not to trust instructions embedded in it. The customer’s text is treated as data the draft is written about, never as instructions to follow.

Caution

An external reply cannot be undone once it has gone. Internal actions carry an Undo on the row for a 24-hour window, but the queue will tell you plainly “Can’t undo — already sent” for a reply that already left. Read outbound drafts at the speed you would read your own.

How do you keep the queue from filling with noise?

Most of a service mailbox is not service, so the platform gives you three ways to get the junk out before it costs anyone reading time.

Ignored senders on the Channels page dismisses mail from an address or a whole domain on arrival. It is the fastest fix for a newsletter or a supplier notification that nobody on the desk needs.

Bulk cleanup groups a cluster of similar mail — several messages from one domain — and offers Unsubscribe all or Ignore all as a single staged decision, so you are not clicking the same call twenty times. Like everything else, it is staged for approval rather than applied on your behalf.

Teach the AI on a triage row saves a plain-language rule about how mail like this should be classified, and you choose whether it applies to that sender’s domain or to every sender on the channel. Those rules are listed under Teaching rules, where you can disable or delete one that has aged badly. They are a separate mechanism from the learning described in how your team learns, and they take effect on new mail.

How do you know the desk is keeping up?

You judge it by the state of the queue, because the reporting that would answer this properly is not built yet.

There is no operations analytics dashboard — no time-saved figure, no automation rate, no first-response chart. What you do get is honest and immediate:

• The Overnight digest per mailbox, split into hot, needs-you and routine.
• Each Channels row’s daily counts — pulled, auto-archived, filed, and how many are in your queue.
• The History tab on Inbound, showing what was done, dismissed or is still awaiting approval.
• The approval history’s outcome column — executed, skipped or failed — which is the only place that tells you a reply actually went out.

First-response time, resolution time, CSAT and reopen rate are not measured. There is no first-response timestamp on a triage item, no clean resolution timestamp, and no CSAT survey source, so those numbers do not exist rather than being hidden somewhere. Judge a day by the open queue and the age of the oldest thing still in it, and do not promise a board an SLA report the product cannot yet produce.

Where should you go next?

Two pages carry the rest of the detail a service desk needs, and both are worth reading before you move a real mailbox over.

• Email and channels — how mailboxes are bound, what each channel can and cannot do, and the go-live switch on sending.
• Working the approval queue — the approval kinds, the undo window, and how to confirm an approved reply actually left.

The same shape applies in other departments: sales, finance and HR. The glossary explains the terms, and the FAQ covers control and data.