An agency runs one support queue per client, usually across many shared channels, and the same few people cover several accounts. The failure is a single pool where a slow answer for one client disappears among fast answers for the others.
The Slack mechanics below come from Slack’s help pages, read on 2026-11-10, and the deactivation article was read again on 2026-11-11. Those pages show no publication date, so check them again before you rely on a plan detail. The thresholds and definitions are my own working rules, not Slack or industry standards.
Start here
- Sort clients by volume. My rule: if a client has at least one thread a week over the last six weeks, it gets its own channel and queue. Anyone below that goes to the shared triage channel.
- Name one invitation owner per client, the person who sends the Slack Connect invitation and can later change that person’s permissions.
- Write your clock definitions and each client’s hours into a one-page agreement before the first reply is timed.
Decide the queue boundary
Use one Slack Connect channel per active client, named after the client, for example client-acme. Keep internal discussion in a channel inside your own workspace.
My rule: a client that writes most weeks gets its own channel and queue. A client that writes less often joins the shared triage channel. Worked example: 14 clients, 3 support staff, and 11 clients writing weekly. Those 11 get channels, and the other 3 share triage.
Split one client’s channel further when any of these holds, using my own thresholds:
- More than about 40 threads are open at once.
- Two teams on the client side expect different response times.
- Staff on one workstream should not see another workstream’s data, for example finance questions versus product questions.
Split by request type, not by your org chart.
Onboard a client and tag shared threads
Run these steps in order, and do not announce the channel until every one is done.
- Record the channel name, the client’s named admin and the invitation owner in your record table.
- Send the Slack Connect invitation with “Permission only to post”. Give “Permission to post, invite, and more” only to the client admin, and only if the contract needs it. A second person checks the organization and the permission before the invitation goes out.
- Add only the staff on that client’s rota.
- Agree in writing the response target, business hours, time zone and holidays.
- Pin a message with the escalation route.
- Check the channel member list after the client accepts. Slack’s invitation article does not say what happens to an unaccepted invitation, so my rule: if the client has not joined 2 business days after sending, the invitation owner asks the client’s contact to confirm the email address and resends.
Shared triage. When several small clients share one channel, tagging has to be explicit or untagged threads go stale. The first staffer who sees a new thread replies in it with the client name as a leading tag, for example “[Acme]”, and adds an eyes reaction. A tag-only reply does not stop the response clock. Whoever holds triage duty that day tags any thread still untagged after 30 business minutes. If a tag is wrong, correct it in the thread and move the record to the right client. Do not delete the original message.
Set who can see and invite
Treat channel membership as the access boundary. Slack’s invitation article says that with “Permission to post, invite, and more”, external people can “Add other people” from “organizations already in the channel”. It does not say they can invite people from outside the channel. Test that in your own workspace before you rely on it.
Plan differences. On Pro and Business+, Workspace Owners manage invitation settings. On Enterprise, Org Owners and Org Admins do. The Enterprise guide says some permissions “can even be customized for each organization you work with”, set from Connections in the admin dashboard. Settings configured centrally apply to every workspace in the org. My inference, not something the guide states: an Enterprise agency can keep a strict default across all clients and loosen one client’s permissions. The invitation article also marks some expanded actions with an asterisk and says those changes “will only apply to the workspace where they were made”, so check each workspace.
Removing an outside person. The steps depend on the plan.
- On Business+ and Enterprise, open Workspace settings, then People, then External people. Owners and admins can disconnect an individual external person there, which Slack says it does instead of removing an entire organization. Removing someone from channels does not revoke their direct message access, so use the individual disconnect when you need to cut all contact.
- To remove a whole client organization from one channel, open the channel, click its name, go to the Settings tab, hover over the organization under Organizations, click the three dots icon, then click Remove and Remove Organization to confirm. Slack says a posting-only organization gets no archived copy when removed, and one with expanded permissions gets an archived copy.
- In either case, check the member list afterwards.
Failure mode: a client admin with the invite permission adds someone from the client’s own organization whom you never vetted. Fix: remove that person from the channel, take the invite permission away from the admin unless the contract needs it, and review the member list. My suggested cadence for that review is quarterly.
When a client contact changes role, ask the client in writing: “Our records show [name] is leaving [client]. Who should hold invitation rights on the shared channels from today?” Then give the new person the invite permission, remove the old contact and check the list again.
Report response time per client
Settle four definitions per client before you report anything. These are my conventions, not Slack’s or an industry standard. The Slack Connect SLA guide covers the reasoning.
- The clock starts at the customer’s first top-level message in a new request. Messages inside an open thread belong to that thread.
- It pauses outside that client’s business hours and holidays, and each client has its own calendar.
- A reply stops the clock only when a named person on your side answers the request in substance. Emoji reactions, automatic acknowledgements and tag-only replies do not count.
- Replies from an AI agent do not stop the clock under this definition. If a client agrees in writing that they should, see the AI section below.
Targets can be tiered, for example 30 business minutes for urgent requests, 2 business hours for normal ones and next business day for low-priority questions. Those figures are examples to adjust, not benchmarks.
For each client and period, report two numbers:
- Attainment: requests answered within target divided by all requests.
- 90th percentile: sort the first-response times and take the value at the 90th percentile. With 42 requests, that is the 38th fastest.
Worked example, invented numbers: Client A had 42 requests and 35 met a 2 business hour target, so 35 of 42. Client B had 6 requests, all on target. The agency total is 41 of 48, which looks healthy, yet Client A missed 7 of 42. The 4 slowest of Client A’s responses sit above its 90th percentile.
Decision rule: with fewer than 10 requests in a period, report the count and the slowest response, not an attainment figure. One late reply in 6 shows as 5 of 6, which reads like a crisis or like nothing, depending on who is looking.
Send each client its own numbers monthly, with the late threads listed. Keep the cross-client comparison internal. The first response time calculator works out deadlines for each client’s hours.
Cover hours and AI agents
Give each client’s hours a named owner and a rota. A client in Singapore and one in Chicago usually cannot share one person. A simple model: one person on duty per time-zone band, a second on call for urgent flags, and the rota published a week ahead. Swaps go through the rota owner, not direct messages.
Pin an out-of-hours message that says what is covered: “Our team replies Monday to Friday, 09:00 to 18:00 Singapore time. For an outage, post URGENT and name [on-call].”
For AI agents, decide per client before you turn anything on:
- Whether the agent replies directly or drafts for a person. My suggestion: drafts first for any client with a response-time commitment.
- Whether an agent reply stops the clock. My default is no, which keeps the human clock honest. If a client agrees to count agent replies, write it into the SLA and report agent first responses as a separate series, with their own attainment and 90th percentile.
- Whether the agent may close a thread.
Failure mode: the agent answers in seconds, the attainment line looks excellent, and a human reply takes three days. Fix: report human first responses on their own, under the default definition, so the number still describes people.
Hand off when the account manager leaves
Slack’s deactivation article says the deactivated person is not notified and their messages and files are not deleted, but they are removed from all channels and signed out. Slack does not say whether anyone else is told, so the client hears from you. The handoff has to happen before the deactivation, in this order.
- List every client channel where the leaver is a member or named contact, from your inbox assignments.
- Add the successor to each channel first, and confirm in each member list that the successor now appears.
- Reassign open threads and check each one’s status.
- Send the client: “Hi [name], [leaver] is moving off the [client] account. [Successor] is your contact from today and has the full thread history.”
- Deactivate the leaver’s account last.
By default only Workspace Owners and Admins can disconnect from an organization. If your successor must be able to end a shared channel, confirm that permission before the handoff.
Failure mode: the leaver is deactivated on Thursday, the successor is added on Friday, and the client writes in between. Fix: the order above, with the successor added before the leaver’s last day.
Keep your own record
Slack’s disconnect article says a posting-only client keeps no copy of the channel after disconnection, and a client with expanded permissions keeps an archived read-only copy that cannot be unarchived. You cannot rely on Slack for your own history, so export each thread when it closes.
Keep one row per request in a single table, in whatever tool your team already uses. Minimum fields:
- Client, channel and a link to the thread.
- Customer first message timestamp, which starts the clock.
- First substantive reply timestamp and the name of the person who sent it.
- Business-hours target, and whether it was met.
- Owner, status, closed date and export date.
Decide where personal data in that table is stored, who can read it, which fields you redact and how long you keep them. Those terms differ by client contract and country, so have counsel set them. This is not legal advice.