I'm currently evaluating our help desk platform's reporting capabilities and have identified a persistent discrepancy in our 'Time to Resolution' (TTR) metrics. The reported averages consistently appear 20-30% lower than manual spot checks of individual tickets suggest, which is skewing our SLA performance dashboards and capacity planning. Our setup involves a multi-stage workflow with automated triage, and I suspect the issue lies in how the platform's native reporting logic interprets ticket state transitions versus our intended business process.
Our workflow can be summarized as follows:
1. Ticket created (via email or web form)
2. Automated tagging and priority assignment (via a rules engine)
3. Assignment to a group queue
4. **`Agent Response`** state (first human touch)
5. Possibly placed in **`Pending`** state (awaiting customer reply)
6. Subsequent **`Agent Response`** states upon follow-up
7. Finally moved to **`Resolved`** state
The platform's default TTR calculation appears to be simple: `timestamp(Resolved) - timestamp(Created)`. This is problematic for us, as the clock runs during the `Pending` state (time waiting for customer response), which we explicitly want to exclude from our internal resolution efficiency metric. We want to measure active work time.
I have attempted to create a custom report using the platform's query builder and calculated fields. The logic I attempted was:
```sql
-- Pseudo-code for calculated field 'Active_Work_Duration'
CASE
WHEN status = 'Resolved' THEN
SUM(duration_between(transition_to('Agent Response'), transition_from('Agent Response')))
ELSE NULL
END
```
However, the platform's reporting engine seems to lack the ability to perform this type of state-transition-based aggregation within a calculated field on a per-ticket basis. It can only sum durations for a single, static field.
My core questions for the community are:
* **Platform-Specific Logic:** Have you encountered similar TTR inaccuracies, particularly in platforms like Zendesk, Freshdesk, or ServiceNow? Which platforms provide the granularity to define a "stop-the-clock" state like `Pending` in their native SLA definitions?
* **Reporting Workarounds:** For platforms with limited native functionality, what are the most robust workarounds?
* Is exporting raw audit logs and processing them externally (e.g., in a Python script using Pandas to reconstruct ticket timelines) the only reliable method?
* Are there proven methods using webhooks to send status transition events to an external database (like PostgreSQL) where custom SQL can compute the correct metrics?
* **Definition Alignment:** How are you operationally defining "Time to Resolution" – is it total calendar time, active work time, or something else? Our requirement is strictly for **agent work time excluding customer wait time**.
I am particularly interested in systematic solutions that can be automated, rather than manual corrections. The volume of tickets makes manual review infeasible. Any detailed analysis of your platform's routing logic, reporting schema, or experience with similar benchmarking challenges would be greatly appreciated.
You've hit on a classic issue. The default `timestamp(Resolved) - timestamp(Created)` logic rarely matches a real-world workflow where you're pausing the clock for customer-dependent waits.
A lot of platforms have a "timer" field or a separate "business hours" configuration you need to explicitly set up. It sounds like your `Pending` state needs to be flagged as a timer pause event. Have you checked if your rules engine can automatically stop/start the SLA timer upon that state transition? That's usually where the fix gets applied.
If the platform's native reporting can't handle this, you might be looking at exporting raw timestamps and calculating TTR externally, which is a pain.
That's a great point about the timer field. We ran into something similar with Jira Service Management. Even after we flagged the 'waiting for customer' state, the default reports still counted that time. The fix was surprisingly simple, we just had to adjust the SLA metric definition from "calendar time" to "business time" in the project settings. Maybe your platform has a similar toggle buried somewhere?
Learning by breaking
The distinction between "calendar time" and "business time" is critical, and you're right that it's often a simple configuration toggle. However, that fix assumes your business hours are correctly defined and static.
In our experience, that toggle can introduce new discrepancies if you have multiple support groups with different operating hours, or if holidays aren't meticulously configured in the system's calendar. The platform might correctly exclude weekends but then incorrectly include a public holiday, creating a smaller but still significant reporting error.
Did you find you had to audit and update the business hour definitions regularly, or was it a one-time setup that remained accurate?
You're making this too complex. It's not about finding a toggle or building external reports.
Your process is wrong. A ticket in `Pending` isn't "work". The clock should stop. If your platform can't do that natively, stop using its SLA module.
Calculate it yourself from the timestamps. One SQL query or a python script that sums only the time spent in active states (`Agent Response`). Export data daily. Build your own dashboard. Takes an afternoon.
These platforms overcomplicate simple metrics.
Simplicity is the ultimate sophistication