When customers DM your team instead of the shared channel

You set up a shared channel with a customer so that everyone on both sides could see the conversation. Then, one afternoon, your CSM gets a direct message from an engineer at the customer: "Quick one, didn't want to ask in the channel." It's a real question, it has a deadline, and it's now in one person's DMs, where nobody else on your team can see it.

Multiply that by twenty accounts and you have a second support queue that nobody tracks. This post covers why customers do this, what it costs, and how to keep private questions private without losing them.

Why customers go private

A DM is rarely a customer being difficult. Usually there's a good reason.

• The channel feels public. Their colleagues, their manager and sometimes their manager's manager are in it. Asking a basic question there can feel like admitting they don't know the product.
• The topic is sensitive. A possible security issue, a colleague's access, a mistake that broke something, or a question about the contract. None of these belong in front of the whole account.
• They know one person. If your CSM helped them once, they'll message the CSM again, by name, because that worked last time.
• The channel is busy. In a channel with a lot going on, a DM feels like the way to be noticed.

All of these are reasonable. The goal isn't to stop private questions. It's to stop them disappearing.

What a DM costs your team

A question in someone's DMs has none of the things a request in the shared channel has.

• No backup. If the person who received it is out, the customer waits, and nobody knows there's anyone waiting.
• No clock. It doesn't appear in any SLA or report, so a slow answer is invisible until the customer complains.
• No history. When that teammate moves to another account or leaves the company, the context goes with them.
• No second opinion. The teammate can't easily pull someone in without forwarding a screenshot of the customer's message.

Don't refuse the DM

The tempting fix is a rule: "Please post in the channel." Customers who had a good reason to go private will hear "we don't want your question". Some of them will stop asking, and you'll find out at renewal.

A better rule is to accept the question privately and make sure your team can see it.

Give customers a private route that your team shares

The core of the fix is a private route that isn't one person's inbox. A few ways to do it by hand:

1. Name the route. Tell customers, in the channel description or a pinned message, that they can ask privately and where to do it. A shared support address works, or a DM to a named on-duty person.
2. Log every private request. When a teammate gets a private question, they add it to wherever the team tracks requests, with the account, the time it came in and who owns it. The text can stay out of the log if it's sensitive.
3. Discuss it in a private internal channel. If the teammate needs help, they ask in a private channel limited to your support team, not in a busy internal channel where the whole company can read it.
4. Reply from the original DM. The customer chose a private conversation. Answering in the shared channel, or asking them to repeat it there, undoes that choice.
5. Hold private requests to the same targets. A private question is still a request. If your SLA says four business hours, it says four business hours here too.

The weak point is step 2. Logging by hand depends on every teammate remembering, every time, in the middle of answering. For more on what to record and why it goes stale, see how to track customer requests in Slack.

Not every DM is a request

A thank-you, a meeting time or a bit of small talk isn't a request, and logging it creates noise. The test is the same as in the shared channel: does someone on your team need to do something? If yes, it's a request, wherever it arrived.

How Thorpe handles it

Private requests are a paid feature, and paid access isn't open yet. The settings are in Thorpe today, but they can't be turned on until it is. Here is how they work.

Instead of messaging a teammate, a customer sends Thorpe a direct message in Slack. Thorpe opens a private request, and your team answers it from a card in a private triage channel.

• The customer's side. The customer messages Thorpe. Thorpe reacts with 👀 and replies that your team will answer in that thread. If they are in customer channels for more than one account, Thorpe may first ask which team the question is about. Your team's replies arrive in that same thread, with the teammate's name in bold.
• Your team's side. A card marked 🔒 Private request appears in the private triage channel, with the customer's name, their company and their message. Replying in the card's thread sends the reply to the customer. A line that starts with note: or 📝 stays internal.
• Same rules as other requests. Private requests have an owner, follow the same SLA policies, and send their SLA alerts to the private triage channel. In the web app, the Private filter shows only private requests.
• Telling customers. You can post a message with an Ask privately button in a customer channel, and you can turn on a short greeting DM for people from the customer's workspace who join a customer channel. The greeting is off by default.
• Who can use it. Only members of your shared customer channels can open private requests. Anyone else is asked to post in their shared channel.
• When it closes. Thorpe tells the customer the request is resolved, and that they can reply in the thread if they need anything else. Thorpe never asks for a rating on a private request.

Thorpe can't read DMs between a customer and one of your teammates, and doesn't try to. It sees only messages sent to Thorpe itself, and stores them only while private requests are on. Turning them on can need one more Slack permission, which an admin approves in Slack. Pick a private channel for private triage, because cards there show the customer's name and message.

The private requests guide covers setup, and the privacy and security page explains what Thorpe stores from direct messages.