How to Use Slack with Clients: Client Channels, Guests or Slack Connect, and What a Small Agency Sets Up First
Your clients want to talk to you in Slack, and you have to decide how before the first message arrives. The choice settles who pays, which Slack plan each side needs, what the client can read and who owns the channel. The wrong choice shows up later as an internal comment a client sees, or a request that sat in a channel nobody owned.
The short answer
- Give every client two channels: a shared one the client sits in, and an internal one only your team sees.
- Pick the way the client joins by what the client already pays for. A client on a paid Slack plan joins by Slack Connect. A client without one joins as a single-channel guest.
- Name both channels with a prefix, so the sidebar sorts them and nobody posts in the wrong one.
- Write a reply window into the shared channel's description before the client's first post.
- Decide once what you do with the client who never opens Slack.
The five ways to bring a client into Slack
Agency owners who describe their setups on r/agency mention four of these: a Slack Connect channel, single-channel guests, a separate free workspace for each client, and keeping the client on email. Multi-channel guests are the fifth, and the one people forget. The table puts them side by side.
| Option | Who pays | Plan needed | What the client sees | Who owns the channel | Fits when |
|---|---|---|---|---|---|
| Slack Connect | Each organization pays for its own Slack | Each organization on a paid plan | The shared channel, plus their own workspace as usual | The organization that created the channel | The client already runs a paid Slack |
| Single-channel guest | Nobody, the role is free | You on a paid plan, the client needs none | One channel | Your workspace | The client has no paid Slack |
| Multi-channel guest | You, billed like a regular member | You on a paid plan | Only the channels you add them to | Your workspace | The client needs two or three channels |
| Free workspace per client | Nobody, per agency owners who do this | Free plan | Everything in that workspace | Whoever creates it | A pilot, or a client who wants a space of its own |
| Nobody | None | Whatever you send | Not applicable | The client will not install Slack |
Slack Connect
A Slack Connect channel can host up to 250 organizations, and each organization must be on a paid Slack plan. An organization that is not on Slack, or not on a paid plan, can be invited to try Slack Connect for free. Whoever creates the channel owns it: only the owning organization can invite other organizations, remove them and manage posting permissions. If you want the agency to stay in control of who is in the room, create the channel from your side.
Inviting is a few clicks in the channel's settings, but Slack says your admins may need to approve invitations you send, and the client's admins may need to approve accepting. Do not schedule a kickoff call that depends on it for the same day. You also cannot add external people to #general.
Single-channel and multi-channel guests
Slack's guest roles come in two types, and guests exist only on paid plans. A single-channel guest is free and sees one channel. For every paid active member in your workspace you can add up to 5 of them, so a 10-person agency can hold 50 single-channel guests. A multi-channel guest sees the channels you specify and is billed like a regular member, which Slack's Fair Billing Policy confirms by listing multi-channel guests with the billed roles and single-channel guests with the free ones.
Neither guest type can create public channels or install apps. Workspace owners and admins invite guests; a member can only request an invitation, which matters for an account manager who wants to add a client on a Tuesday afternoon.
A free workspace per client
Some agency owners in that thread create a new free workspace for each client, because nobody pays. Three costs follow from how Slack works, in my reading rather than Slack's words. Your team signs into a second workspace for every client, the history lives outside your own workspace, and anything built on top of your main workspace, such as the agent below, does not reach it. It suits a short pilot better than a long retainer.
Email is a legitimate answer. Some owners in the same thread keep clients out of Slack because things get lost and clients expect a fast response, and they save Slack for the team.
Choose by what the client already pays for
Choose the setup per client by what the client already pays for: a client on a paid Slack plan fits Slack Connect, and a client without one fits a single-channel guest, which is free.
One setup for every client is easier to explain, and it fails in both directions. If you push every client into Slack Connect, clients on free plans cannot join. If you push every client into guest seats, you take on admin work for clients who would have brought their own Slack. The rule is one line on the onboarding checklist: ask the client whether they pay for Slack, then use the matching row. A client who needs a project channel and a billing channel is a multi-channel guest, so count that seat before you promise it.
Two channels per client, named so nobody posts in the wrong one
The pattern agency owners describe most clearly is one shared channel the client joins plus an internal channel for the same client, where the team talks candidly. In that thread, one owner says the client account manager carries information between the two as needed. That works, and it is also where a request goes missing: if the carrying is a person's memory, it fails on the day that person is out.
Give the two channels names that cannot be confused. Slack's guidance on channel names recommends a standard set of prefixes, such as help-, team-, proj- and triage-, and notes that prefixes sort the sidebar when it is alphabetical. Slack's prefixes were written for internal channels. This is my recommendation for clients, built on the same idea:
- ext- for the shared channel the client sits in, for example ext-brightside.
- int- for the internal twin, for example int-brightside.
With those two prefixes the sidebar groups every shared channel together and every internal twin together. Add a description to both, since Slack advises a topic or description so people know what a channel is for. The shared channel's description states what belongs there and the reply window below. The internal channel's description names the account lead.
Internal naming is covered in how to organize Slack channels, and a new client's setup steps are in the client onboarding checklist.
A reply-time rule, and the client who never opens Slack
Put a reply window in the shared channel's description before the client posts anything, because a client who gets one instant answer in Slack learns to expect all of them.
Agency owners in the r/agency thread describe the same thing: in a chat tool there is an expectation of a fast answer, and in client services a fast answer usually means a change. Every instant reply teaches the client what the channel is for. After a month the window you never stated is the window the client invented from the fastest reply they ever got.
A written window makes the rule yours. For example, the shared channel is read at set times each business day, and anything urgent goes to a named phone number or email address. State it in the description and the welcome message, then keep it. A window you break teaches the same lesson as no window.
The second problem runs the other way. In a second r/agency thread, agency owners say clients set up a Slack account and never use it. One reply describes tagging the client constantly, getting them onto the phone app and texting when they miss a message. Another keeps email as the main channel and lets the client message only their account manager in Slack. These are individual accounts, but they agree on the shape of the fix. Decide a fallback per client at onboarding:
- If the client has not posted in the shared channel by the end of the second week, ask them by email whether Slack is working for them.
- If the answer is no, move that client to email, keep the internal channel, and have the account lead paste decisions into it. The internal twin still earns its place, because it becomes the one record of what the client said by other routes.
A worked example: one client's week
Example: a 12-person agency called Fernwood Digital has a client called Brightside Bakery. The shared channel is ext-brightside, with the client's owner as a single-channel guest because the bakery does not pay for Slack. The internal channel is int-brightside, and Dana, the account lead, is in both.
During the week the bakery's owner posts four things: a new opening-hours banner for the site, a question about the invoice, an unrelated idea for a loyalty promotion, and a change to the Friday newsletter.
On Friday Dana asks the Kipwise agent from int-brightside: "List what Brightside asked for in ext-brightside since Monday." The agent reads the shared channel with Dana's own Slack access and replies in the internal channel with the four items and the date each one was posted. This works because ext-brightside is a public channel in Fernwood's workspace. The agent does not carry a private channel's messages into another channel, so if your client channel is private, ask in your direct message with the agent instead. Dana then says: "Create an Asana task for the banner and the newsletter change and assign them to Priya." For each one the agent shows an Approve card, and the task exists only after Dana presses it. The invoice question goes to finance by hand, and the promotion idea waits for the next planning call.
Then Dana asks for the repeat: "Every Monday at 8:30, list what Brightside asked for in ext-brightside over the previous seven days." Creating a scheduled request needs approval once, and the Monday post lands in int-brightside with the list. Turning items into tasks is still a request Dana makes, with its own cards.
The agent does not reply to the bakery on its own, does not move messages between channels by itself and does not read texts or WhatsApp. The bakery's owner sees the same shared channel as before, and the only one who answers the client is a person.
The agent connects to Asana in Slack and ClickUp in Slack with each person's own login, so it acts with Dana's access. Who owns a task once it exists, and when it escalates, is covered in how to stop client requests from disappearing into Slack.
What guests can and cannot do with the agent in a shared channel
If the client is in a shared channel where the agent is installed, the client is a guest, and the product treats guests differently from your team.
- What guests can do. Guests use their own connected accounts, such as their own Gmail, Google Drive, Calendar or GitHub, and the agent offers a guest a private Connect button when one is needed.
- A warning before they connect. The Connect button carries a warning whenever people outside your company can read the conversation. It appears before the button is pressed, because an answer drawn from a personal account is posted into the channel, where your team reads it too. The person connecting decides.
- What stays closed. Guests cannot reach your internal knowledge base, posting as the bot, team settings, usage, credits or Kipwise support. If a guest asks for one of those, the agent says it is reserved for members of the workspace.
- When the agent joins a channel. It sends a direct message to the person who added it, asking whether the channel is team-only or will include people from outside the company. When outside people are already there, it shows the guest guide instead, and an admin decides per item whether to share it with guests or stop sharing it.
- Microsoft Teams. Guest turns are not available there yet.
On cost, guests in Slack Connect channels draw only from the team credit. Kipwise pricing is $10 per user per month with a minimum of 3 users, and the team credit is the shared part of that, so a chatty client can use the pool your own people rely on.
Failure handling
- The client sees an internal channel. A guest sees only the channels you add. If you used a multi-channel guest, check which channels that guest was added to.
- An invitation sits unaccepted. Admin approval on either side is the usual cause for Slack Connect. Ask the client to check with their Slack admin, and offer a single-channel guest seat as a fallback.
- The client wants to keep the history. In Slack Connect the owning organization can remove others and keeps the channel, so decide before you create it which side should own it.
What to do next
Pick the client whose messages scatter the most across email and DMs. Ask them whether they pay for Slack, create ext- and int- channels, set the reply window in both descriptions, and add the agent to the internal channel only. At the end of that week, ask it what the client asked for in the shared channel and approve the tasks it proposes.
