A customer has escalated hard, insisting your product is broken, but the fault is in their own integration. How do you run the investigation and deliver the finding?
When a customer insists a product bug is actually their integration issue, investigate from a shared request ID, prove the boundary failure with reproducible evidence, and deliver the finding without embarrassing the customer engineer.
5 min readUpdated 2026-08-15
0
Answer
Short answer
When a customer escalates a product bug that is really an integration issue, avoid arguing about blame and anchor everyone on one reproducible request. Show what left their system, what reached yours, check your side honestly, then deliver the finding as a shared mechanism so their engineer can fix it without being publicly corrected.
Was this answer helpful?
Likely follow-ups
→Their engineer disputes your finding and sends a trace that appears to support them. What do you do next?
→The misconfiguration was caused by an example in your own documentation. Does that change the conversation, and how?
→Your account executive wants this framed as a customer error in the renewal narrative. How do you handle that?
→How would you decide whether this incident warrants a product change rather than a documentation change?
An escalation arrives with a conclusion attached: the product is broken. If you contest that conclusion in the first exchange, everything afterwards is read as defence, and you have lost the ability to be believed later when you actually know something. So the opening move is to accept the symptom completely and be unhelpfully specific about it. Which request, at which timestamp, with which identifier, from which environment, and what did the customer expect instead. A symptom is not a claim about cause and nobody has to concede anything to describe one.
That specificity is also the fastest technical route. Escalations run long mostly because the two sides are looking at different traffic. Getting to one request identifier that both parties can look up in their own logs converts the discussion from two opinions into one object, and it usually does so within an hour.
Narrow the fault to one side of the boundary
The investigation itself is a boundary problem. There is traffic leaving the customer's system and traffic arriving at yours, and somewhere between the two an assumption differs. The work is to bisect that boundary with evidence the customer can generate themselves, because a finding they produced is one they will accept.
Loading diagram…
The interesting part of that sequence is the hop the customer's own engineer cannot see: what left their application and what reached your edge are two different things, and the proxy in between is nobody's declared responsibility. Most integration escalations that look like product bugs live in exactly that gap — a rewritten header, a stripped field, a retry that changed the method, a certificate chain that only fails from one region.
The practical version is a minimal reproduction that removes their infrastructure from the path. Ask them to issue the same call from a laptop with a plain HTTP client, using the same credentials, and compare it against what their pipeline sends. If the laptop works and the pipeline does not, the fault is inside their environment and you did not have to say so; the experiment said it. Keep an eye on timing too. Faults that appear only on some requests are usually the shape of a load-balanced set of clients where one of them has an old configuration.
Check your own house honestly first
Before you tell anyone the fault is theirs, you must have genuinely tried to find it on your side, and you must be able to say what you checked. Look for a change on your end in the window when the symptom started — a release, a config rollout, a rate-limit threshold, a certificate rotation, a deprecation that quietly began returning a different status code. Enterprise customers are entitled to that, and if you skip it you will eventually be wrong in the one case where it mattered, which is expensive in a way no apology fixes.
There is a second, subtler question: did your product make this misconfiguration easy? A field that fails silently when absent, an error message that says "invalid request" without naming the field, a documented example using a value that only works in a sandbox — each of these makes a customer error partly yours. Finding one changes both the remedy and the tone, and volunteering it is the single most credibility-generating thing you can do in an escalation.
Delivering it so nobody has to be wrong in public
This is the part the question is really about. The finding is that a named engineer on the customer's side configured something incorrectly and then escalated to their own management claiming a vendor defect. If that lands in an email thread that includes their director, you have solved a technical problem and created a political one, and the person you embarrassed will be the same person you depend on for every future integration.
The sequence that works has three steps, in order. First, take it to the engineer alone, before it is written anywhere, and present it as a shared finding rather than a verdict. Second, agree with them what goes in the written update and let them be the one to send it. Third, keep your own written summary factual about the mechanism and silent about the fault.
Two ways of saying the same thing:
Framing to avoid
Framing that works
"This is not a bug, the header is missing from your requests"
"We traced the identifier through both sides. The header is set in your application and absent by the time it reaches us, which points at the hop in between"
"Your team misconfigured the retry policy"
"The retries are arriving as GET rather than POST. That is a known behaviour of some proxy defaults and it explains every failed record"
"As we suspected, no product defect was found"
"Root cause sits in the request path. Here is the change, here is how we verified it, and here is what we are fixing on our side so it fails loudly next time"
Notice what the right-hand column does. It describes a mechanism rather than allocating blame, it uses the plural where the work was genuinely shared, and it always carries something you are changing too. That last element is not politeness — it is what makes the update readable by their director as a resolved joint investigation rather than as a vendor scoring a point.
Say the awkward part on a call, never first in writing. Written words get forwarded without their tone, and a sentence that was gentle in a conversation reads as an accusation in a thread the author never saw.
Where candidates get this wrong
The common failure is treating the escalation as a question of who is right, and the giveaway is a candidate who reaches for the phrase "not a product bug" as though it were the deliverable. It is not: the customer's pipeline is still broken, their business is still affected, and "correctly not our fault" is worth nothing to them. The finding is the halfway point. What completes the job is the fix landing in their environment, a written mechanism their management can read without anyone losing face, and one concrete change on your side so the same misconfiguration cannot silently succeed for the next customer.
An escalation ends when the customer's system works and their engineer still trusts you, and only one of those two is a technical problem.