🎧 Customer Support report
Mon 8/31/26 to Sun 9/6/26
Report generated: Mon 9/21/26 @ 10:26pm Central
Last sync: Mon 9/21/26 @ 6:04am Central, 8,719 tickets.
Replayed: tickets and messages after that date are excluded, but each ticket's status is its status today, not its status then.
❤️ HEALTH
Is the desk ok right now?
📊 Activity
| Day | Msgs in | <1h | 1-2h | 2-4h | 4h+ | Waiting |
|---|---|---|---|---|---|---|
| Mon 8/31 | 26 | 10 | 9 | 0 | 4 | 0 |
| Tue 9/01 | 23 | 10 | 8 | 2 | 0 | 0 |
| Wed 9/02 | 16 | 7 | 2 | 1 | 0 | 1 |
| Thu 9/03 | 31 | 10 | 5 | 6 | 0 | 1 |
| Fri 9/04 | 19 | 11 | 4 | 1 | 0 | 0 |
| Sat 9/05 | 0 | 0 | 0 | 0 | 0 | 0 |
| Sun 9/06 | 0 | 0 | 0 | 0 | 0 | 0 |
Business hours only. Rows do not sum to messages in: 23 more were closed without a reply, nearly all of them a client saying thank you. The ones that were not are under Bad closes.
🚨 Needs attention now
6 messages are waiting on a reply. Longest first.
🔇 Bad closes
⚠️ 67 of 82 closed threads in this window are unjudged. An unjudged thread cannot appear as a bad close, so what follows is a floor, not the number.
To finish the window: python3 freshdesk/thread_evaluation.py --as-of 2026-09-07 --threads threads.md, read and judge them, then --verdicts verdicts.jsonl, then re-run this report.
15 of 82 closed threads judged: 7 answered, 0 bad closes, 8 not a support request.
No bad closes in the 15 judged.
📈 Against your own baseline
| This week | 4w baseline | ||
|---|---|---|---|
| Tickets in | 86 ↑ | 59 | +46% |
| Messages in | 115 ↑ | 98 | +18% |
| Closed | 82 ↑ | 58 | +43% |
| Still open | 4 | – | |
| Median response | 53m ↑ | 40m | 🔴 +32% worse |
| p90 response | 7.7h ↑ | 3.5h | 🔴 +119% worse |
| Still waiting | 2 | – |
Response times are per inbound message, not per ticket, and include messages still waiting at their elapsed-so-far duration. Dropping unanswered ones would mean ignoring a customer improved the percentile.
p90 is the number to watch: a fast median with a slow p90 is a desk that looks healthy and has a tail of people who were left.
Rows with – for a baseline are cohort-aged: this week's tickets are days old and earlier weeks' have had a month to close, so comparing them would read as worse every week no matter what.
⏱️ Response distribution
| Wait | ||
|---|---|---|
| p50 | 39m | half were faster |
| p75 | 1.9h | |
| p90 | 3.3h | 10% waited longer than this |
| p95 | 8.1h | |
| p99 | 6.3d | 1% waited longer |
| max | 18.1d |
| Answered | Messages | Share |
|---|---|---|
| < 1 business hour | 246 | 57% |
| < 4 hours | 392 | 91% |
| < 1 business day | 407 | 95% |
| < 3 business days | 420 | 98% |
| > 7 business days | 4 | 0.9% |
429 inbound messages over the trailing 4 weeks. A single week is too few messages for a p99 to mean anything.
⚡ What changed
- p90 first response degraded to 7.7h from a baseline of 3.5h.
- 4 tickets have been waiting on a reply for more than 7 business days, the longest 33.7d.
🔍 DIAGNOSIS
Why, and who it is coming from.
⏳ Where the time goes
92.8d of business time across 86 tickets, 39% of it waiting on us.
| Owed by | Hours | Share |
|---|---|---|
| Us | 36.6d | 39% |
| The client | 56.2d | 61% |
| Our time per ticket | ||
|---|---|---|
| p50 | 1.1h | half held us less |
| p90 | 8.8h | the tail that sets the week |
| max | 6.3d |
Derived from message timestamps, not from Freshdesk status. A span that starts with a customer message is ours until we reply; one that starts with our reply is theirs until they write back. Private notes move nothing. Business hours only, and the clock stops when a ticket closes. Tickets still open are counted to now, so their share can only grow.
🏢 Who
Ranked by change against each company's own 4-week baseline, so a client going from one ticket to six outranks a steady heavy user.
| Company | Week | Baseline | Change |
|---|---|---|---|
| inchecksolutions.com | 25 | 13.2 | +89% |
| verification@ | 14 | ||
| vsquality@ | 8 | ||
| michaelvelasco@ | 2 | ||
| essentialscreens.com | 9 | 2.0 | +350% |
| etaylor@ | 4 | ||
| clientcare@ | 3 | ||
| dhill@ | 2 | ||
| srascreening.com | 11 | 7.2 | +52% |
| ckranz@ | 8 | ||
| cgajjar@ | 2 | ||
| sorders@ | 1 | ||
| 3rddegreescreening.com | 4 | 1.8 | +129% |
| jimmy.waters@ | 2 | ||
| keely@ | 2 | ||
| argusverify.com | 3 | 1.0 | +200% |
| robin@ | 2 | ||
| chris@ | 1 | ||
| nu.edu | 2 | 0.0 | new |
| askhr@ | 1 | ||
| hrsdp@ | 1 | ||
| accounts.google.com | 2 | 0.0 | new |
| no-reply@ | 2 | ||
| simpliverified.com | 3 | 1.2 | +140% |
| verifications@ | 2 | ||
| andrea@ | 1 |
🏷️ Tags applied
Computed from the store, not inferred.
- 14Escalated
- 4Robin_review
- 2provided_contact_info
- 2not_sure_if_received_09/03
- 13rd_Party_Verifier
- 1not_sure_if_received_09/04
- 1not_sure_if_received_09/08
💬 Themes
Inferred: read from the ticket bodies, not computed.
Our own replies stopped reaching two of our largest clients
The week's dominant cost, and not a verification problem at all. First Choice and InCheck both stopped receiving our email, which was only found because clients chased us for answers we had already sent.
- 22027 internal ticket opened once both clients reported the same thing
- 22030 DKIM settings tested from the inside
- 22095 a day of test messages to First Choice before one landed
- 22031 First Choice confirming the first message that arrived
- 22167 resolved only after the client whitelisted our domain on their end
- 21688 client chased twice for documents that would not open, then apologised to for a reply they never saw
- 22040 the same answer sent twice, 11.8 hours apart, because nobody knew the first arrived
- 22046 and again, 10.4 hours apart, on a five-file escalation
- 22049 and again, 10.3 hours apart
Parchment, from every angle at once
Nine tickets, and the one that matters is the last: a client asked to have the product removed from their SLA. Every other bullet is why.
- 22129 First Choice asking to remove Parchment from their education SLA entirely
- 21905 wrong person's report uploaded, Jennifer M Pine for Jennifer E Pine, dispute filed with Parchment
- 21793 the same order closed as verified two days earlier, from a result nobody could trace
- 21742 request submitted 8/17 with no update, client chasing it two weeks on
- 21916 institution cancelled the request, still open and pending three days later
- 21965 second cancellation at the same school, client took the work back in-house
- 21935 client asking why cancellations carry no reason, and for it to be supplied up front
- 21736 no match on the initial query, so the order closed with no fallback to a call
- 22156 Parchment fee never integrated into the file
Orders closed with no attempts, because the blueprint said email only
Seven tickets from three clients, all the same surprise: an order dispatched without an email address under an email-only SLA closes itself, and the client sees a reference marked unobtainable that nobody ever tried.
- 21868 three orders returned unobtainable with no calls or emails, client's own client upset
- 21927 more of the same, same client
- 21928 and again, same client, same night
- 21743 three reference orders closed for no reference email on a blueprint that forbids our research
- 22141 reference closed unattempted after the client was told that reference had already answered
- 21785 no attempts since dispatch because only a phone number was supplied
- 21751 order should have been raised to Admin when the email failed, and was not
Work finished, but never arriving on the client's side
Eight tickets where the verification was complete at our end and invisible at theirs, so the client paid us in chasing time for work we had already done.
- 21749 results present here, missing in TAZ, pushed manually
- 21796 verification completed on a call the client could see in the notes but had no result for
- 22039 completed by phone, not in the client's system
- 22147 completed order the client could not see, and a second one checked just in case
- 22168 verifier answered after the file had already closed as expired
- 22069 reference answers requested because the inbound call left no record
- 22080 same reference, asked again the same afternoon
- 22173 same reference, asked a third time the next day
The dialer answering badly
Five tickets where a call was made and the call itself was the problem.
- 21952 verifier reported a bad experience with one of our dialers and asked us to stop
- 21917 dialer completed a verification the verifier had said to route to HR, with no month detail
- 21840 DOT additional questions returned N/A because the dialer never asked them
- 21803 AI agent skipped two questions, a human had to call the reference back
- 21789 reference called for under a misspelled name, refund issued
The wrong party contacted
Four tickets, four different ways of reaching someone who was never going to be able to answer.
References who called back and could not get through
Two tickets against our own callback line during a phone-provider outage.
🌟 PRAISE
Client praise, in their words.
No noteworthy praise this week.