Tone guides stop at how to sound. A communication standard states which replies you owe, how long each may take, who sends it, and what never appears in a customer thread. The time values below are starting points. Set them against your own SLA before you adopt them.
Which replies you owe, and when
| Reply | Owed when | Who sends it |
|---|---|---|
| Acknowledgement | 1 business hour after the customer’s first message in a new request. For an outage, data loss or blocked production system: 15 clock minutes, at any hour | Outage: the on-call person on the roster, with the support lead alerted at once. Otherwise any named person |
| Progress update | By the promised update time, at most 1 business day apart | The request owner |
| Handoff notice | In the same hour the request moves to another person or team | The person handing off |
| Resolution check | Before the request is marked solved | The request owner |
Two definitions keep the table honest.
New request. A different problem, or the same problem raised by a different person, is a new request with its own 1-hour clock. A follow-up question on the same problem in the same thread is the same request and restarts nothing; answer it by the next promised update time. A customer who adds an outage to a routine thread has opened a new request, so say so: “This sounds separate from the export question, so I’m treating it as its own request.”
Business hour. Count in one time zone per account, written into every template, on the hours you publish. A message that arrives on a closed day or after hours counts as arriving at the next opening. Outage messages ignore hours. If your roster spans regions, keep a holiday calendar for each, and at the end of each region’s day the owner of an open request writes the handoff note and names who holds the next update time.
The rule that makes the first row work: “If an acknowledgement cannot contain the answer inside 1 business hour, it must contain the time of the next update. An acknowledgement without a time does not count as a reply under this standard.” The clock runs from the timestamp of the customer’s first message to the timestamp of your reply. For defining that clock inside an SLA, see the Slack Connect SLA first response time guide.
Acknowledgement templates with a commitment time
In a shared channel, reply in the customer’s thread:
“Thanks, Dana. Priya is reproducing the export failure on the Q3 account now. You’ll get the cause or a next step from us by Friday 12:00 CT.”
By email, with the same content:
“Hi Dana, we’ve received this and assigned it to Priya Shah, who is reproducing the export failure today. You’ll hear from us by Friday 12:00 Central with the cause or a next step.”
Worked example. A customer writes on Thursday at 16:20 Central. Your hours are 09:00 to 18:00 Central, Monday to Friday, and the investigation target is one business day, so the answer is due Friday at 16:20. The acknowledgement is due by 17:20 on Thursday. Promise Friday 12:00, which is 4 hours 20 minutes ahead of the answer deadline. Promise the update time rather than the final deadline, so a slipped fix still leaves you an honest update to send. The first response time calculator works out deadlines if your hours are not a simple 9 to 6.
If nobody on the roster reads the customer’s language, send the acknowledgement on time in your working language and, when it matches how you are reading the message, add: “We’re reading this with a translation tool, so please send the file ID and a screenshot. We’ll confirm the next step by Friday 12:00 CT.”
Progress updates and what pauses the clock
A request that passes its promised update time with nothing posted is a missed commitment, even when the work is moving. Post on time anyway, and say what is still unknown:
“Still on this. What we know: the export fails only for files over 2 GB. What we’re doing next: Priya is testing a fix on staging. Next update from us by Friday 12:00 CT, even if the fix isn’t ready.”
Decision rule for the update timer: if you are waiting on the customer, it pauses until they reply, and you say so: “We’re waiting on the file ID from you. Once it arrives, our next update is due within 1 business day.” If you are the blocker, it keeps running. The closing window in the closing section is the one timer that runs while you wait on the customer, because the wait is its purpose.
Keep one update time on every open request, next to the owner’s name. A request without an update time is the one that gets forgotten.
Email, Slack, several askers and engineering
When the same problem arrives in both, the earlier message starts the clock and the request has one owner. Post the commitment time in both places. Reply where the customer wrote last, with one line in the other: “Replied in Slack, thread from 14:05.” Merge the duplicate and tell the customer: “You also emailed this, so I’ve merged the two and we’ll answer here.”
If several people at the customer ask about one outage, answer once in the channel and mention each asker. If one of them messages an engineer directly, the engineer replies “Thanks, I’ve added this to the request. Please post it in the shared channel so the whole team sees it,” and posts nothing else.
Escalation to engineering. Support decides to escalate, with one rule: if you cannot reproduce it in 30 minutes, or it affects more than one customer, it goes to engineering. The request owner stays the only voice to the customer. Engineering does not set the update time; the owner does, after asking engineering for an estimate. The clocks keep running while engineering works, because the customer’s wait is the same either way. If engineering has no estimate, the update says so: “Engineering is investigating and has no estimate yet. Next update from us by Friday 12:00 CT.”
Internal discussion stays out of the customer’s thread
Anything you would not want the customer to read goes to an internal place. Assume anything posted in a shared channel or its threads is read by people at the customer, and do not count on editing or deleting to undo it. Keep internal discussion in an internal Slack channel, or in the internal note field if your helpdesk has one.
Threads need one extra check. Per Slack’s help page, a thread reply stays in the thread unless the sender checks the box below the message to send it to the channel. On desktop you can also select “Send reply to this channel” from the three dots icon after sending. On mobile, press and hold the thread reply. A colleague who replies “Priya, can you take this, the customer keeps pinging” inside the customer’s thread has just told the customer the team is annoyed.
Write the handoff note so the next person can act without reading the thread:
“Account: Northwind, Growth tier. Asked: export fails over 2 GB since Tuesday. Tried: re-export, second browser, file ID 4471. Promised: update by Friday 12:00 CT. Need from you: decide by Thursday 17:00 CT whether we offer the manual export.”
Then tell the customer, in the thread:
“I’m bringing in Marcus from our billing team, who owns invoice corrections. He has this thread, so you won’t need to repeat anything. You’ll hear from him by Tuesday 15:00 CT.”
Never ask a customer to paste passwords, API keys or personal data into the channel. Say: “Please don’t paste passwords or keys here. Send the file through the secure link in the pinned message.”
Who may speak, and where AI agents fit
Name two people per account, a support owner and a backup. Everyone else answers internally and lets the owner post. The Slack Connect guide says only the organization that owns a channel can invite other organizations. As a recommendation, not a Slack rule, make the support lead the person who holds that invite and removes the customer’s people when a contract ends, the same business day.
- If the answer commits money, a delivery date, a data deletion or a policy exception, the account owner replies. Support posts only the acknowledgement and the date.
- If the question is a security questionnaire or a contract term, the account owner replies after checking it against what you have agreed.
- Engineers do not post in a customer channel. Support turns their findings into the customer message.
- If both named people are out, the support lead owns the request. If the lead cannot post within 4 business hours of the acknowledgement deadline, the account owner or the lead’s named deputy answers the customer.
For AI agents, these are defaults to adopt as of late 2026, not industry rules. An agent’s automatic acknowledgement counts as the 1-hour reply only if it carries a specific update time and a named human owner. The request owner owns any time the agent promised, so let agents promise only times from a list a human set, such as “next business day, 12:00.” A draft a person approves belongs to that person, who corrects it in the thread if it is wrong. Tell the customer when an agent sent a message unreviewed: “This reply was sent by our support assistant; Priya is reviewing the thread and will follow up by Friday 12:00 CT.” Reviewed drafts need no label. If your contracts or local rules require disclosure, take that to counsel.
Phrases to ban, and what to send instead
| Banned | Why it fails | Send instead |
|---|---|---|
| “That’s not our problem.” | Refuses without a route | “That part sits with our billing team. I’ve asked them, and you’ll have an answer from me by Thursday 12:00 CT.” |
| “Per policy, we can’t do that.” | A wall with no option | “We can’t extend the trial on this plan. What we can do today is move you to the next tier. I’ll confirm by Wednesday whether a one-time extension is possible.” |
| “It works on our end.” | Dismisses the report | “I couldn’t reproduce it with the steps you sent. Could you send the file ID and a screen recording of the step before the error?” |
| “Please be patient.” | Gives no time | “Next update by Friday 12:00 CT.” |
| “As I mentioned before.” | Blames the reader | “To restate it in one line: the limit is 2 GB per file.” |
| “We’ll get back to you soon.” | Undefined | The day, time and time zone. |
Closing a request without closing it on a thank-you
Before marking a request solved, ask one specific question, with a date. Say it is asked on Monday:
“Before I mark this solved: can you confirm the Q3 export works on your side? If I don’t hear back by end of day Wednesday, I’ll mark it solved, and you can reopen it by replying in this thread.”
Decision rule: the window is 2 business days from the question, and it does not pause, because silence is the signal. If the customer confirms the outcome, solve it. If they say thanks without confirming, ask the same question once more and restart the window. If Wednesday ends with no reply, solve it and send:
“Marking this solved. We haven’t heard back since Monday’s question about the export, so we’ve closed it. If it fails again, reply in this thread and it reopens with Priya.”
A reopened request keeps its owner, and the 1-business-hour acknowledgement applies again. A reply within 7 days of the solve is the same request. After 7 days, open a new one and link the old thread in the internal note. Report “replied” and “resolved” as different states.
Turning the standard into an audit
Put the table, templates and banned list on one page, and link it from the channel topic or a pinned message. Audit weekly: pull 20 requests and count acknowledgements sent after 1 business hour, acknowledgements without a time, updates posted after their promised time, internal remarks in customer threads, banned phrases, and credentials or unredacted screenshots. Fix each miss with the person who made it, then sample 20 again the following week.