What is the post-purchase support cost framework?
The post-purchase support cost framework is a way of seeing what support costs a store beyond the salaries of the people who answer tickets. It counts tickets per order by type, assigns each type a handling cost from the time it takes to resolve and a resolution cost from what resolving it triggers, and multiplies through to a total per type. The result is a ranked list of what post-purchase support actually costs, and where the cost comes from.
The Order Support FTE on ftes.ai reports the inputs from the help desk and the store, and uses the framework in its monthly review to propose which upstream fix would remove the most cost.
What are the framework's four inputs?
The framework has four inputs, all available from a store's help desk and order data, and none of them requires an estimate that cannot be checked.
- Tickets per order by type: post-purchase tickets in a period divided by orders in the period, split by type such as order status, return, exchange, damaged, missing, order edit.
- Handling cost per type: the median time to resolve a ticket of that type multiplied by the loaded cost of the person's time, or the metered token cost when a Digital FTE resolves it.
- Resolution cost per type: what resolving the ticket triggers on average, such as the refund amount, the replacement's landed cost, or return shipping paid by the store.
- Cause tags per type: the upstream cause the Order Support FTE tags on each ticket, such as a vague estimate, a packaging fault or a listing that over-promised.
How is the cost calculated, with a worked example?
The cost per type is tickets per order for that type, multiplied by orders in the period, multiplied by the sum of handling cost and resolution cost per ticket. A labelled worked example, illustrative only: a store shipped ten thousand orders in a month. Order-status tickets arrived on twelve percent of orders, took five minutes each at a loaded cost of thirty per hour, and triggered no refund: twelve hundred tickets at two and a half each is three thousand. Damaged-item claims arrived on one percent of orders, took twenty minutes each, and triggered a replacement with a landed cost of eighteen: one hundred claims at ten plus eighteen each is two thousand eight hundred.
The order-status type costs more in total; the damaged type costs far more per ticket. The framework shows both, which is why the next step is not simply to answer order-status tickets faster.
Why rank by total cost and then look at the cause?
Ranking by total cost shows where the money goes; the cause tags show what would stop it. In the worked example, the order-status tickets are mostly tagged to a checkout estimate that promised delivery two days sooner than the carrier delivers. Fixing the estimate removes most of that type at no handling cost at all. The damaged claims are mostly tagged to one product's packaging; a packaging change removes most of them and their replacement cost.
A faster reply reduces handling cost only. An upstream fix reduces tickets, handling and resolution cost together, which is why the framework always ends with the cause and not with the response time.
Where does a Digital FTE change the arithmetic?
An Order Support FTE changes the handling cost line, because routine tickets it resolves inside policy are metered in tokens rather than in a person's minutes, and it changes the cause line, because it tags every ticket so the upstream fix is visible. It does not change the resolution cost of a ticket the policy says to refund; a refund inside the limit costs what it costs. Its effect on resolution cost comes through the exchange-first rule, where the customer's logged choice of an exchange replaces a refund, and through the cause tags that remove tickets altogether.
The framework keeps those effects separate so the owner can see which one is doing the work. Handling cost falling while tickets per order stays flat means the FTE is answering; tickets per order falling means an upstream fix landed.
How should the framework be applied month to month?
The framework should be applied monthly, on the month's orders and tickets, with the ranked list beside the previous month's so the owner sees which types moved and why. The Order Support FTE's monthly review in the Performance tab shows the inputs, the ranking, the dominant cause per type, and the fix it proposes for the top one. After a fix ships, the next month's tickets per order for that type is the honest measure of whether it worked.
Peaks distort the rate for a month, and the review says so rather than reading a seasonal spike as a failure. The rate per order is chosen precisely because it survives volume; the cause tags are chosen because they survive the peak.