Playbook, developer tools company
Most complaints here are technically specific and frequently correct
A complaint on a developer product is rarely about service. It is about a change: a deprecation whose removal date lands inside a code freeze, an interface that altered shape in a release the reader believed was safe to take, a default that changed quietly and broke a build at the worst moment. The person writing usually has the evidence and is often right, which makes this the one pair where an apology template is the wrong instinct.
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 grievance is a specific, checkable technical claim rather than an experience, so it can be right or wrong on the facts, and weighing it in a chat window is worse than routing it to somebody who can.
- Whether a change counts as breaking is precisely what is being argued about, and it is an argument with a real technical answer that nothing in a chat window is in a position to settle.
- The complaint is frequently already public in an issue thread or a forum, so whatever is said here is likely to be read beside whatever a maintainer said there, and inconsistency between the two becomes its own problem.
- Deprecation timing is the recurring cause: a removal date announced with reasonable notice can still land inside somebody's change freeze, and what they are asking for is time rather than sympathy.
How it arrives
- you removed that in a minor release and broke our build
- the removal date lands inside our change freeze
- the default changed and nothing in the changelog mentions it
- this is the second breaking change this quarter
- who do i escalate to about the migration timeline
- your documentation still describes the old behaviour
What has to be indexed for this to work
| The versioning policy, saying what may change in which kind of release | The promise you are being measured against. Without it, every argument about whether something was breaking is opinion, and there is nothing true for an assistant to quote back into the conversation. |
|---|---|
| The deprecation register, with announcement and removal dates | What is going, when it was announced, when it goes and what replaces it. Those dates are the substance of most of these complaints and they should be findable in one place rather than scattered across release notes. |
| The route for asking about a removal date, if one exists | Whether a customer can request more time and who decides. If there is no such route, publish that too, because the request will be made regardless and an unanswered one becomes a second complaint. |
| Where formal complaints go, and the response commitment | The address or route, and the period. Naming it makes a handover read as an escalation rather than as a deflection, which is the difference between somebody waiting and somebody posting. |
The reply
I am not going to argue about whether that counts as a breaking change, and I would not be the right thing to argue with anyway. What I can give you is the versioning policy, which sets out what may change in each kind of release, and the deprecation register entry with its announcement and removal dates so you can see exactly what was published and when [1]. Where a removal date falls inside a freeze, there is a route for asking about timing and it is described there rather than being something I could agree to [2]. Leave your name, your work email, the organisation and the version you are on, and this goes to the team as a complaint rather than as a support question.
Declining the argument in the first sentence is the only honest move, because nothing here can adjudicate a technical claim and this reader would spot an attempt within a line. Handing over the policy and the dates lets somebody who is probably right check that for themselves. Labelling the handover as a complaint matters, since otherwise it arrives looking like another question.
Where it stops
The trigger. The reader uses the word complaint, disputes whether a change was breaking, asks for a deadline to be moved, or says they are raising it publicly.
This should reach the team as a complaint rather than land in a support queue. Leave your name, your work email, the organisation and the version you are on, and I will send it with what you have written so nobody has to ask you to repeat any of it.
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 or disagree that a change was breaking, because that is a technical judgement for somebody with the authority to make it.
- Never apologise on behalf of the company in terms that concede fault.
- Never promise that a deadline will move, an exception will be granted or a change will be reversed.
- Never say the team is already aware of a complaint, or that other people have raised the same one.
Questions
- Should it try to defuse this before handing over?
- It should be accurate and brief, which defuses more than any softening language would. The reader has a version number and a changelog entry in front of them. Quoting the policy and the dates treats them as somebody capable of checking, which is what they wanted.
- These end up in a public thread anyway. Does the chat reply matter?
- It matters more for that reason. Whatever it says is likely to appear beside a maintainer's reply, so it should quote published material and commit to nothing, which is the only way the two can end up agreeing.
- Can it record a complaint formally?
- No. It collects a name, an email and what was written and sends that to the address you nominate, with the details stored as well so a delivery failure does not lose one. The formal record is created by whoever receives it.
Keep reading
- Everything for a developer tools companyOn a docs site an assistant competes with search, not a phone line. Version skew, deprecations and error strings decide whether it earns its place.
- 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.
- Answering a pasted stack trace without ever seeing the projectDevelopers paste the error, not the concept. What an assistant can say about a failure it cannot reproduce, and where the guessing has to stop.
- Install, credential, first successful call, in the language they are writingQuickstart questions are narrow, repetitive and decide whether an evaluation continues. What to index per language so the answer lands.
- Does this work with the runtime they have already committed toCompatibility answers age badly and end up in procurement decks. Keeping support matrices, deprecations and removal dates answerable.
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.