What does the surface measure?
From the connected helpdesk: ticket volume, first response and resolution times, resolution rates, CSAT where it is collected, and the current backlog with its age. Per agent and in total, for any range. Each ticket is joined to the customer and, where it references one, the order, so support is measured next to the commerce it concerns.
That join is what makes revenue at risk computable: the value of the orders sitting in the unresolved queue, ranked so the largest exposure is visible rather than buried behind the oldest ticket.
- Ticket volume, first response time, resolution time and resolution rate, per agent and in total.
- CSAT where the helpdesk collects it, shown next to the queue composition that produced it.
- The current backlog with each ticket's age.
- Revenue at risk: the value of the orders attached to unresolved tickets right now.
- Recurring themes, with the volume and the money behind each one.
Why do per-agent figures need composition?
An agent handling refunds and disputes will be slower than one handling delivery questions, and a table of averages will make them look worse. The engine shows the composition of each agent's queue alongside their times, so the reading is fair.
The purpose is coaching and staffing, not ranking people. A team whose slowest resolution times sit on one ticket type has a process problem, and that is what the surface is built to reveal.
What is revenue at risk in the queue?
Unresolved tickets attached to orders carry the value of those orders. Summed, that is the revenue at risk right now, and it is the figure that justifies adding a shift on a Monday rather than a feeling that the queue looks long. Ranked, it tells the team which conversation to pick up first.
It is computed, not estimated: the orders are real orders, the tickets are real tickets, and the join is on the reference the helpdesk holds.
What do customers keep asking about?
Tickets cluster. Where is my order, does this run small, how do I return, is this in stock at the Leeds shop. The engine surfaces the recurring themes with their volume and the money behind them, so a brand can fix the cause instead of answering the question faster.
A theme about sizing points at returns analytics and a page fix. A theme about delivery points at the warehouse backlog. A theme about stock points at the inventory analyst. The value of measuring support inside a commerce engine is that each theme has somewhere to go.
What the engine does not do to your helpdesk
It does not reply to customers, close tickets, or change anything in the helpdesk. It reads tickets, messages, agents and CSAT, and reports. Where a reply is drafted, it is drafted for a person to review and send from the helpdesk, and the engine records that the draft was produced.
Support remains the team's tool. The engine's contribution is measurement and the joins the helpdesk cannot make on its own.
Which roles work here on ftes.ai?
The Order Support FTE works the exception queue and is judged on orders resolved inside the promise. The Voice of Customer FTE owns the themes and is judged on the issues it retires by getting the cause fixed. Both read this surface and both propose rather than act.
A brand connecting a helpdesk sees volume, speed and backlog from the first sync, and the themes once there are enough tickets in the window to cluster honestly.
How does a support theme become a fix?
A theme is a cluster of tickets with a shared cause and a money figure attached. The engine routes it to the surface that owns the cause: sizing themes to returns analytics and the page fix, delivery themes to the warehouse backlog, stock themes to the inventory analyst.
That routing is the difference between a support report and a support improvement. Answering the same question faster is a smaller win than removing the reason it was asked, and the money attached to the theme is what justifies the work.