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?

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.

Do not argue about the cause yet

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.

sequenceDiagram
    participant CS as Customer system
    participant GW as Their gateway
    participant API as Your API
    participant Log as Your logs
    CS->>GW: Request with header set
    GW->>API: Header rewritten by proxy rule
    API->>Log: Records what arrived
    Log-->>CS: Same identifier, different payload

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:

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.

© 2026 Preptima. Originally published at preptima.com.