Playbook, SaaS company
It is the middle of the night somewhere and the product is still running
There is no closing time to describe here, because nothing shuts. The product keeps working, and what stops is people replying. Customers merge those two facts constantly, which is why an unanswered message at two in the morning is read as an outage, and why the useful material is a coverage window with a time zone written next to it.
Why this is not the general answer
The handling pattern for out of hours holds across every trade. What follows is the part that does not.
- Nothing closes, so the honest statement is about when people reply rather than about when the service is available, and those are two separate facts customers routinely collapse into one.
- Response commitments often vary by plan, which means the true answer depends on something the assistant cannot see, and the only way round that is publishing the commitment per tier instead of per customer.
- Coverage is written in one time zone and read in another, so a window without a zone against it produces a complaint rather than an expectation.
- Incident response and ordinary support are separate arrangements with separate hours, and the message arriving overnight is usually about the first while your published hours describe the second.
How it arrives
- is anyone there at the weekend
- what time zone is your support team in
- do we get overnight cover on our plan
- when will someone reply if i send this now
- are you closed over the holidays
- who do we contact overnight if the service is down
What has to be indexed for this to work
| Coverage windows with the time zone written beside them | The days and hours somebody is answering, stated in a named zone rather than in local time. Every complaint about a slow reply that turns out to be a misread window comes from omitting the zone. |
|---|---|
| Response expectations by plan, exactly as published | What each tier is told to expect, in your own words. The assistant cannot see which plan somebody is on, so the material has to be readable as a table the visitor can locate themselves in. |
| Holidays as dated entries | The specific dates the team is not answering, including the ones that differ between the countries your team sits in. A general note about public holidays quietly becomes a wrong answer, and it does so at exactly the time nobody is there to correct it. |
| The out of hours route for incidents, and what qualifies | Where a customer goes overnight when the service itself is the problem, which plans that applies to, and what does not qualify. Put it where the assistant reaches it first, because somebody with a production problem types before they read. |
The reply
The team answers during the windows on our support page, and those are stated in a named time zone, which is worth checking against yours before counting hours [1]. Response times differ by plan and the table there says which applies to each. If the problem is that the service itself is down, that has its own overnight route rather than waiting for support to open, and it is on the same page [2]. I cannot see your plan or tell you when somebody will reply to a particular message. If you leave your name, the account email and what has happened, it goes to the team as it is.
It puts the time zone caveat in the first sentence, because that is the misunderstanding this whole cell exists to prevent. The incident route is separated out and named, since the person writing overnight is usually in that category and not in the queue category. It declines to predict a reply time, which is the promise most likely to be quoted back the next morning.
Where it stops
The trigger. The visitor asks when somebody will reply to their specific message, asks what cover their plan includes, or describes a production problem outside the published windows.
I cannot see your plan or predict when somebody will pick this up. Leave your name, the account email and the workspace name, and if the service itself is affected, use the out of hours route on our support page rather than waiting for this message to be read.
It stops answering before it guesses, says who will pick it up, and asks for the one thing that makes a reply possible. Nothing about it reads as a dead end.
Never say this here
Out of bounds
- Never promise a reply time that is not the one you publish for that plan.
- Never say somebody is available now, because there is no reliable sense of the time where the visitor is.
- Never treat a message about the service being down as an ordinary out of hours enquiry.
- Never say a ticket has been opened, queued or prioritised, since nothing here creates one.
Questions
- What is the actual value of answering overnight if we cannot reply?
- Most overnight messages are answerable from documents: how something works, what a plan includes, where a setting is. Those get answered at three in the morning by material you already wrote. What is left is a message with the account details already attached, waiting for the team rather than for the customer.
- Can it tell somebody what response time their plan gets?
- It can quote the published table and let them find themselves in it. It cannot see which plan an account is on, so it must not say your plan gets a four hour response, however confidently the visitor states which plan they are on.
- Should the fallback message mention the out of hours route?
- Yes, with a line saying what it is for. Composing it into an answer means it only surfaces when the question matches something, and the messages that need it most are the ones typed fastest and worded worst.
Keep reading
- Everything for a SaaS companyOne widget serves prospects, trialists and paying customers. What it can answer about plans and limits, and what has to reach a person.
- Handling out of hours in generalThe difference between an emergency route and a message form, and why an honest wait time beats a promise you cannot keep.
- Tier boundaries are the real question, not the headline priceSeats, overages and mid cycle changes are where SaaS pricing questions actually land. What an assistant can quote, and what it must never invent.
- Explaining how a charge was calculated without ever seeing the chargeProration, tax numbers and missing invoices arrive constantly. What the assistant explains from policy, and the point where it takes a name.
- A cancellation message is a retention conversation that has not happened yetThe assistant cancels nothing. It can be exact about notice, the last charge and what happens to data, then get a person into the conversation.
Try it on your own material
Upload a document or point it at your site, paste one line of HTML, then ask it something only your business could answer.