At 08:40 on a Tuesday, a finance manager at an accounting client emails: invoice exports have stopped working and month-end billing is due. The consultant replies “Thanks, looking into it” and gets to work. At 12:15 the managing partner phones your account manager to ask whether anyone is dealing with it. The fix arrives at 13:00. The technical work was fine; four hours of silence is what the client will remember.
Most support teams have a response target. Fewer have service desk customer communication guidelines that say when the next message will arrive. Here is a policy to agree with clients, a communication matrix and six scripts.
How often should a service desk update a client?
Set the update schedule by business impact, and state the next update time in every message. While a serious interruption is stopping the client’s work, keep a short fixed interval (for example, every 30–60 minutes); for lower-impact issues, update when something material changes or at an agreed check-in. A next-update promise you keep is worth more than a fix estimate you cannot support.
There is no universal interval. Atlassian’s incident communication guidance recommends never going more than one hour without an update while an issue is still affecting customers’ ability to use a product, and always saying when the next one will come. That is a ceiling for a live outage, not a rule for a password reset.
Four client messages that are easy to confuse
- Acknowledgement. A person has read the request, understands the impact and owns it. An automatic receipt is not an acknowledgement.
- Diagnostic update. What is known, what has been ruled out and what is being tried now.
- Restoration estimate. When usable service or a workaround is expected, given only with its assumptions.
- Resolution notice. What was done, how it was checked, what limits remain and how to reopen.
A next-update time is a communication commitment you control; a restoration estimate is a forecast you often do not. Promise the first firmly and qualify the second.
Choose an update cadence by impact, support hours and stage
Work through these steps once, agree the result with each client and record it.
Step 1: Classify by business impact. Use the client’s language (“finance cannot bill”, not “export job failing”). Impact sets the starting interval.
Step 2: Apply support hours and time zones. An update rule that runs in business hours must say what happens at 17:00. State the time zone in every promise (“by 14:30 SAST”).
Step 3: Adjust by stage of investigation. Uncertainty is highest at the start, so keep intervals shortest there. Once the client confirms a workaround works, you can agree a longer interval. Do not lengthen it on your own.
Step 4: Name the owners. One person owns the ticket. For serious incidents, name a separate communication owner so the person diagnosing is not interrupted to write. Google’s SRE workbook makes the same split in its incident response chapter: a Communications Lead gives periodic updates while an Operations Lead works the problem. A small consultancy can simply decide who writes before the incident starts.
Step 5: Define the escalation path. Decide when a missed update, changed estimate or complaint goes to a team lead or account manager, and who tells the client.
Decision point: if the people on shift cannot keep the interval you would like, promise a longer one you can keep.
What every client update should contain
Every operational update should answer five questions:
- What is affected? In business terms, and for whom.
- What do we know? Facts only, including what has been ruled out.
- What are we doing now? The current action, not a list of everything tried.
- Does the client need to do anything? Say “No action needed” when that is true.
- When is the next update? A time, a time zone and a promise to write even without news.
A diagnostic update written for engineers (“The export worker is throwing a 500 on the batch endpoint; we’re checking the logs and the API token”) is accurate but gives the client nothing to act on or repeat to their own management. The 10:00 update in the example below carries the same facts in the client’s language.
Waiting for the client, waiting for a supplier and no progress
Waiting for the client. Ask precise questions, say why each matters and agree a reminder date. A “Waiting” status is not permission to go quiet. Your SLA says when you must respond or resolve, and whether the clock pauses depends on what you agreed; your update policy says how the client stays informed in between, paused or not.
Waiting for a supplier. The client came to you, not your supplier. Keep your update commitment even when the supplier is silent, and say how you are chasing them.
No material progress. Send the update anyway, on time. Make it useful by naming what was ruled out and what is next.
Hypothetical example: an accounting practice cannot export invoices
Here is the same kind of failure as the opening story, handled with a cadence policy. A 25-person accounting practice uses an IT provider for application support. On the last working day before month-end, invoice exports to their accounting system fail. The provider’s matrix rates this high impact (billing is blocked, but invoices can still be viewed), and because billing is due today, it agrees hourly updates with the client rather than its usual interval.
09:05 SAST — acknowledgement (ticket owner). “Thanks, Priya. We understand invoice exports are failing and month-end billing is due today. Nomvula owns this ticket. Existing invoices are unaffected. We are investigating now and will update you by 10:00 SAST, even if we are still working on it.”
10:00 — investigation update. “Invoice exports are still failing; existing invoices are safe. We have ruled out user permissions and your account settings and are now testing the connection to your accounting system. No action needed from you. Next update by 11:00 SAST.”
11:00 — the difficult exception. At 10:40 diagnosis points to the accounting system supplier, who acknowledges the fault but gives no fix time. Nomvula’s instinct is to wait for a real estimate. Instead she keeps the promise: “The fault is with the accounting system’s export service, not your data. We have reported it to the supplier and are chasing them. They have not given a fix time, so we will not guess one. As a workaround, we can produce your invoice file manually for today’s run. Please confirm by 12:00 if you want that. Next update by 12:00 SAST, even if the supplier has not replied.”
12:00 — workaround accepted. Priya confirms the manual file and her team can bill. With the workaround confirmed, Nomvula agrees with Priya to move to two-hourly updates, as Step 3 allows: “Next update by 14:00 SAST, or sooner if anything changes.”
13:00 — changed estimate. The supplier now estimates 16:00, a material change, so Nomvula writes early using the changed-estimate script below: the new time, why it moved, the fallback if it slips again (the manual file covers tomorrow’s run too) and “Next update by 15:00 SAST.”
14:50 — resolution. Exports work again, ahead of the supplier’s estimate. The notice explains the cause, the test performed, that the manual file needs no re-export, and how to reopen.
What made this work was not speed but predictability: every message landed when promised, and none of them invented a fix time.
Service desk customer communication guidelines: a matrix to agree with each client
The intervals are starting examples to adapt, not standards.
| Impact level | Audience and channel | Owner | Next-update rule | After hours |
|---|---|---|---|---|
| Critical: service down, no workaround | Named client contacts and their manager; phone for first contact, then email or portal | Communication owner, separate from the fixer | Every 30–60 minutes while active, plus on material change | Continue only if an out-of-hours arrangement is agreed; otherwise state when updates resume |
| High: major degradation, or a workaround exists | Requester and named contact; email or portal | Ticket owner | Agreed interval within support hours (for example every 2–4 hours); state workaround status each time | Final update before close of support day, with the time the next one will arrive |
| Standard: one user or process affected | Requester; ticket reply | Ticket owner | On milestone change, or at the agreed check-in date | None; next update on the next support day |
| Waiting for client | Requester; ticket reply | Ticket owner | Reminder on the agreed date; confirm what is still needed | None |
| Waiting for supplier | Requester and named contact | Ticket owner | Keep the interval for the impact level; report chasing activity | As per the impact level |
Six client update scripts
1. Acknowledgement “Hi [name], thanks for reporting this. We understand [what is affected] is [impact on their work]. [Owner] is responsible for this request. [What is not affected, if known.] We will update you by [time, time zone], even if we are still investigating.”
2. Investigation update “[What is affected] is still [state]. So far we have ruled out [items]. We are now [current action]. [Workaround, or ‘There is no workaround yet.’] No action is needed from you. Next update by [time, time zone].”
3. Information request “To take the next step, we need: [question 1, and why it matters]; [question 2, and why it matters]. Please do not send passwords. We will keep working on [what we can do meanwhile] and will check back on [date] if we have not heard from you.”
4. Supplier wait “The cause is with [supplier/system], not [the client’s data or setup]. We reported it at [time] under reference [ref] and are chasing them. They have not yet given a fix time, so we will not guess one. [Workaround.] Next update by [time, time zone], whether or not they have replied.”
5. Changed estimate “We previously expected [outcome] by [old time]. That has moved to [new time] because [reason in plain language]. If that slips again, [fallback]. Next update by [time, time zone].”
6. Resolution “[What was affected] is working again as of [time]. The cause was [plain explanation]. We checked it by [test]. [Remaining limitation or follow-up, if any.] If you see the problem again, reply to this message and we will reopen this request rather than start again.”
Where this policy breaks down
A cadence policy cannot fix unclear ownership: if nobody is named, nobody writes. Nor can it rescue vague messages; repeated “still investigating” updates train clients to ignore you.
The most common failure is the missed promise nobody notices. Each month, review a sample of tickets: updates delivered on time divided by updates due gives a simple reliability measure, but read the messages too, because an on-time update can still be empty. Check that “Waiting” tickets have a follow-up date and that no update promised an unsupported fix time.
Put the policy to work this week
Draft your matrix, rewrite the last update on three current tickets using the five questions, then agree the matrix with one client before rolling it out. If support follows a project, settle these expectations at the start of the engagement, alongside the decisions in your project charter. For the wider ticket routine, see handling customer tickets effectively; for how the service desk fits into broader service management, see information services management.
The policy is easier to keep when each ticket has one owner and a full history of what the client was told. Chronodesk Service Management brings email, WhatsApp and web requests into the same ticket queues with clear ownership, and its Advanced plan adds response and resolution SLA timers with escalation before a breach. Your next-update promises still need a human owner.
Frequently asked questions
How often should a service desk update a client during an outage?
While a major interruption is still stopping the client’s work, agree a fixed interval and keep to it. Atlassian recommends never going more than one hour without an update in that situation; an interval such as 30 to 60 minutes is a common starting point to agree. Treat any figure as a policy to agree with your client, not an industry rule.
Is the next-update time the same as the resolution time?
No. A next-update time is a communication commitment you control, so you can almost always keep it. A resolution or restoration estimate depends on diagnosis, suppliers and testing, so it is often uncertain. Promise the first firmly and give the second only with its assumptions.
What should we send when there is no progress to report?
Send the update anyway, at the promised time. Say what has been ruled out, what is being tried now, whether the workaround still stands and when the next update will arrive. A short, honest message keeps the client from assuming nobody is working on it.
Should the person fixing the issue also update the client?
For routine requests, yes, the ticket owner usually handles both. For a major interruption, name a separate communication owner so the person diagnosing the fault is not interrupted every half hour. The communication owner still needs direct access to the technical lead.
Does putting a ticket in a waiting status stop our obligations?
It does not stop your ownership. Whether it pauses an SLA clock depends on the service rules you agreed with the client. Either way, record what you are waiting for, agree a follow-up date and keep the client informed.