Bug, config, or user error? The most expensive question in support

Every ticket on a technical queue opens with the same silent question, whether anyone says it out loud or not: is this a bug, a config problem, or user error?

Everything downstream hangs on that answer. A bug goes to engineering. A config issue gets a walkthrough from support. User error means the docs have a gap. Three different destinations, three different owners, three different costs - and the choice is typically made in the first ten minutes, by whoever picked the ticket up, holding the least information anyone will have about the problem all week.

The cost of a wrong branch is asymmetric

Triage mistakes aren't all the same size, and the dangerous ones aren't the ones you'd guess.

Call a real bug "user error" and you've told a customer that the product's mistake is theirs. They stop trusting your support long before they stop paying you - and the bug ships on, manufacturing the same ticket for every other customer who hits it. The most expensive sentence in support is "this is expected behaviour" when it isn't.

Escalate a config issue as a bug and an engineer context-switches off the roadmap, spends half a day reproducing, and comes back with "their webhook URL was wrong." Do that a few times and engineering starts treating support escalations as noise - so when the real bug arrives, it queues behind the scepticism you've trained into them.

Refuse to commit either way and you get the ping-pong ticket: support asks for logs, engineering asks if it reproduces, everyone touches it, nobody owns it, and the customer watches a week go by. Nobody decided wrongly. Nobody decided at all.

Why the fork is genuinely hard

This isn't a competence problem. The three possible answers live in three different systems, and no one at triage holds all of them:

• User error is a claim about the docs - what the product is supposed to do.
• Config is a claim about this customer's setup versus what the API actually does, which is not always the same thing.
• Bug is a claim about the code - often about what changed in it recently.

Answering the question properly means checking documented behaviour, retracing actual behaviour, and scanning recent changes - three investigations, before a single reply is written. Under queue pressure, nobody does that for every ticket. So the fork gets taken on pattern-matching: this smells like the webhook thing from March. Experienced people pattern-match well. That's precisely why the fork silently routes every hard ticket to your most experienced people - and why it misroutes whenever the pattern is new.

The most expensive question in support is answered in the first ten minutes, on the least information - by pattern-match, because evidence is too expensive to gather.

Answer the fork by looking, not guessing

Now flip it around: what if the evidence were already gathered before a human took the fork? The docs checked, the API behaviour retraced, the recent changes scanned - with the findings attached to the ticket at arrival.

That's what Brocklore does. The moment a ticket is created, it investigates across your docs, API references, and codebase, and proposes an answer to exactly this question - bug, config, or expected behaviour - with the evidence it's based on: the doc section, the endpoint, the commit. The person doing triage still decides. They just decide the way senior people do - by looking - without the half-day of looking. We've written up how the investigation works.

The fork isn't going away. The guessing can. See how Brocklore answers it with evidence.