Capture is not processing

Capture and processing are two different sets

Capture is every ticket the brand received, whatever closed it. Processing is the subset an operation actually handled. They are related the way a population is related to a sample, and treating them as one number is the mistake the rest of this article is about.

Razviel's architecture separates them on purpose. The design pulls the tickets the brand closed on its own out of the helpdesk and classifies them into the same record shape as the ones it handled. Capture is the denominator. Processing is the numerator, and only for the metrics that are about how the operation performed.

None of that requires anything exotic. The tickets a brand closed alone are already sitting in the helpdesk, and the helpdesk lists them through the same paginated endpoint as everything else, closed among the statuses it returns. The purchase side of the join is retrievable too: the store's commerce API returns orders with the customer attached, filterable by date and status. What is missing in most operations is not access. It is the decision to classify what the operation did not touch.

A captured ticket that the brand resolved alone carries less than one handled end to end. There may be no policy reference, no action list, sometimes no satisfaction signal. The record is designed to hold that: a field with no source is left blank and flagged, never filled in with a zero. A declared blank is information about the data. An invented zero is a lie with a decimal point.

A rate carries its denominator whether or not anyone writes it down

The figures in the next two paragraphs are invented, and exist only to display the arithmetic. They are not a measurement of anything, and Razviel publishes no performance figures.

Take a hypothetical store that receives ten thousand support contacts in a month and routes four thousand of them into an automated layer, which closes three thousand two hundred of those without a person. Two rates describe that month. Against the four thousand it processed, the layer closed eighty percent. Against the ten thousand the store received, it closed thirty-two percent.

Both are arithmetically correct. Neither is a lie until it is published without its denominator, at which point one becomes a claim about an operation and the other becomes a claim about a store, and the reader has no way to tell which was meant. The same ambiguity runs in the other direction: a value total computed over the processed set understates the money the brand's support actually moved, because most of the money moved in tickets the operation never saw.

This is why the denominator cannot be a reporting preference chosen per chart. It has to be a property of the metric, fixed by what the metric is for.

Two families of metric, and the test that separates them

Performance metrics — resolution rate, first response time, handled volume, time to close — take the processed set as their denominator, and nothing else. Widening them to captured volume would credit or blame an operation for work it never had access to. A resolution rate is a statement about the tickets the resolver processed, and it has to be written that way or it is not a measurement.

Value metrics — revenue protected, refund exposure, credit issued, cost per resolution — take all captured tickets, because the money moved regardless of who was holding the conversation. But they carry a mandatory second dimension: who resolved it. That produces two readings of the same figure. The total view is the brand's own truth about its support — what the whole function generated. The isolated view is the return on the platform — which share of that total came from the tickets it operated. Both are required. Never inflate the return by counting the brand's own value as the platform's; never hide the total by publishing only the platform's.

The tie-break is one question, and it is about the metric, not about the layout. A metric that measures a financial value belongs to all tickets, always separable by who resolved them. A metric that measures how an operator performed belongs to the processed only. Two figures sitting in the same panel can belong to different families, and forcing them onto one denominator because they share a border is how a report begins lying by arrangement.

"Resolved by the brand" names two different events

The first sense: the ticket entered, was processed, and was handed to the brand because no policy covered it or because the brand claimed that class of case for itself. The second sense: the ticket never entered at all — the brand's own team closed it in the brand's own helpdesk, and it was captured and classified afterward.

Both produce a ticket whose attribution reads brand. They have nothing else in common. One is an outcome of routing. The other is a fact about traffic that routing never saw.

Add them together and the escalation rate stops being a measurement. It charges the operation for every ticket the brand handled on its own, which is to say for the brand's own volume, and it moves whenever the brand's internal team gets busier — an event that says nothing about the operation at all.

So attribution alone does not carry enough. The record has to hold whether the ticket entered, separately from who closed it. In the design, the record is identical no matter who resolved it: a ticket the AI closed carries the same transcript, the same action list, the same values as one a human closed. Attribution is the only discriminant, and the record never gets poorer because software finished it.

Solved is a state, not an outcome

There is a third denominator problem underneath the first two. Even inside the processed set, a solved ticket is not a successful ticket. Solved means a processed interaction ended. Whether it went well is decided after it ended, and somewhere else.

A resolution counts as good when two signals agree: the customer rated it well, and the ticket did not come back for the same reason. Either signal alone has a known failure. Satisfaction alone catches the customer who was happy in the moment and whose problem returned a week later. Non-reopening alone catches the customer who never wrote again because they left. Together they are a usable label, and the design uses that label — not the closure — as what marks a resolution worth repeating.

An operation that reports solved tickets as successes is measuring its own throughput and calling it quality. That is the same error as the wrong denominator, one level down: a number that is easy to produce standing in for a number that describes what happened.

The takeaway

A support rate is only as true as the set it is computed over. Capture is every ticket the brand received; processing is the subset an operation handled. Performance metrics belong to the second, and value metrics to the first, separable by who resolved them. For a Shopify Plus brand whose volume also closes in the helpdesk, the returns portal and the tracking page, a report built on processing alone describes an operation, not the support the brand delivered.

What to check in any support report, your own or a vendor’s:

1. The denominator, written down. Every rate names the set it is over. A resolution rate without one is either a claim about an operation or a claim about a store, and the reader cannot tell which.
2. The family of each metric. Resolution rate, first response time and handled volume take the processed set. Revenue protected, refund exposure and credit issued take every captured ticket, split by resolver. Two figures in one panel can belong to different families.
3. What closed without being counted. The tickets the brand closed on its own already sit in the helpdesk, listed through the same endpoint as the rest. A report that never pulls them cannot reconstruct them later.
4. The two meanings of brand. A ticket routed to the brand and a ticket the brand’s own team closed before anything routed it carry the same attribution. The record holds whether the ticket entered, separately from who closed it, or the escalation rate absorbs the brand’s own volume.
5. Solved versus good. A closed ticket is a state. A resolution counts as good when the customer rated it well and it did not come back for the same reason; either signal alone has a known failure.

A rate is worth reading once it says which set it is over, and whether that set is all the support the brand received.