Playbook, SaaS company
The angry message is from an administrator with a renewal coming
The person writing is rarely the person most affected. An administrator is relaying the frustration of a team, they have a seat count and a renewal date behind them, and the complaint is often not about something that broke but about something you deliberately changed. That combination is why routing this quickly is a commercial act rather than a courtesy.
Why this is not the general answer
The handling pattern for complaints holds across every trade. What follows is the part that does not.
- The complainant writes on behalf of colleagues, so the message carries other people's frustration plus a number, and that number is how many seats are on the contract.
- A large share of these are about a change rather than a failure: a capability moved behind a higher tier or was withdrawn, and the customer is inside a term they cannot simply leave.
- Reliability complaints reference incidents the assistant has no record of, so acknowledging the experience without characterising what happened is the only wording that survives being screenshotted.
- These arrive close to renewals far more often than the timing suggests, which means the value of a fast handover here is measured in contract value rather than in queue length.
How it arrives
- this is the third outage this month and nobody has explained anything
- you moved a feature we pay for to a higher plan
- we have been waiting a week for a reply from support
- who do we escalate to above support
- we want out of the contract
- nobody told us the price was going up
What has to be indexed for this to work
| The escalation route, with a role at the end of it | Who a customer reaches above ordinary support, how, and what happens then. A complaint answered with the same contact form it came through is the thing that turns a frustrated administrator into a public one. |
|---|---|
| The published service commitment and what it entitles somebody to | What is promised, to which plans, and the process for claiming against it. Quote it exactly, because a paraphrase of a commitment is treated as the commitment by the person reading it. |
| How changes and withdrawals are announced | Where deprecation notices go, how much warning you give, and what happens to a customer mid term when something moves tier. Complaints about changes are largely complaints about notice, and this is the document that answers them. |
| The terms covering price changes at renewal | How much notice is given before a price change, in what form, and to which contact. Publishing it does not make a rise popular, and it does move the argument from whether you were allowed to whether it is worth paying. |
The reply
I am sorry about this, and I would rather it reached somebody than stopped with me. Complaints go to the escalation route on our support page, which names who picks them up and how quickly [1]. Where a capability has moved between plans, the notice we give and what happens to customers mid term are set out in the change policy [2]. I cannot see your account, your incidents or your contract, and I am not in a position to agree what should happen. Leave your name, the account email, the workspace name and the dates involved, and it goes across today.
It apologises for the experience and says nothing at all about whether the company was at fault, which is the distinction that keeps the message safe without sounding cold. Pointing at the change policy answers the complaint that is really about notice. And it collects the four things needed to investigate, so the first human reply is substantive rather than a request for details.
Where it stops
The trigger. Every complaint, and immediately on any mention of leaving, of legal advice, of a public post or of a claim under the service commitment.
This needs a person rather than me, and it needs one today. Leave your name, the account email, the workspace name and the dates, and it goes to the escalation route on our support page with all of that attached.
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 agree that a service commitment was missed or breached, since nothing here can see what happened.
- Never accept that a customer is entitled to leave, be released from a term or stop paying.
- Never attribute a problem to a named person, a team or a third party.
- Never offer a credit, a discount, an extension or a free period to calm somebody down.
Questions
- Should it try to answer the complaint rather than route it?
- No. It should recognise it, point at the escalation route and collect the details, and nothing else. A cited quotation from a policy page in reply to an angry message about repeated outages is the most inflammatory output available, because it proves nobody read it.
- Somebody says they want to cancel mid term. What then?
- That is a contract conversation, not a support one, and it should reach a person immediately with the workspace name attached. Explaining the notice terms first reads as an obstacle and makes the outcome worse than the complaint was.
- Does routing complaints through a widget look impersonal?
- Less impersonal than an unread inbox. What matters is where it lands and how fast: an enquiry that reaches a named role the same day beats a perfectly worded form that goes to a shared address nobody owns.
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 complaints in generalThe job is to route, not to resolve. Acknowledge without conceding, name the escalation route, and get it to a person fast.
- Somebody wants into the beta, and the answer is not a dateAn invite queue for an unfinished capability is not a line. What may be said about early access, and why no date may be given.
- It is the middle of the night somewhere and the product is still runningThe software runs all night and the team does not. What to publish about coverage windows, time zones and plan based response times.
- 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.
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.