🎧 Customer Support report
Mon 8/10/26 to Sun 8/16/26
Report generated: Mon 9/21/26 @ 10:02pm 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/10 | 25 | 7 | 8 | 2 | 1 | 0 |
| Tue 8/11 | 25 | 15 | 5 | 2 | 0 | 0 |
| Wed 8/12 | 31 | 17 | 3 | 1 | 1 | 1 |
| Thu 8/13 | 33 | 13 | 6 | 6 | 1 | 0 |
| Fri 8/14 | 28 | 11 | 2 | 6 | 0 | 0 |
| Sat 8/15 | 0 | 0 | 0 | 0 | 0 | 0 |
| Sun 8/16 | 0 | 0 | 0 | 0 | 0 | 0 |
Business hours only. Rows do not sum to messages in: 34 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
4 messages are waiting on a reply. Longest first.
🔇 Bad closes
⚠️ 79 of 79 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-08-17 --threads threads.md, read and judge them, then --verdicts verdicts.jsonl, then re-run this report.
📈 Against your own baseline
| This week | 4w baseline | ||
|---|---|---|---|
| Tickets in | 82 ↑ | 66 | +24% |
| Messages in | 142 ↑ | 115 | +23% |
| Closed | 79 ↑ | 64 | +22% |
| Still open | 3 | – | |
| Median response | 38m ↓ | 45m | 🟢 -14% better |
| p90 response | 2.9h ↓ | 4.3h | 🟢 -33% better |
| Still waiting | 1 | – |
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 | 43m | half were faster |
| p75 | 1.8h | |
| p90 | 3.8h | 10% waited longer than this |
| p95 | 15.8h | |
| p99 | 16.3d | 1% waited longer |
| max | 29.3d |
| Answered | Messages | Share |
|---|---|---|
| < 1 business hour | 272 | 60% |
| < 4 hours | 412 | 90% |
| < 1 business day | 428 | 94% |
| < 3 business days | 435 | 95% |
| > 7 business days | 16 | 3.5% |
456 inbound messages over the trailing 4 weeks. A single week is too few messages for a p99 to mean anything.
⚡ What changed
- 2 tickets have been waiting on a reply for more than 7 business days, the longest 18.7d.
🔍 DIAGNOSIS
Why, and who it is coming from.
🏢 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 |
|---|---|---|---|
| firstchoicebackground.com | 31 | 14.8 | +110% |
| kennia@ | 19 | ||
| samanthad@ | 5 | ||
| paige@ | 4 | ||
| essentialscreens.com | 5 | 1.0 | +400% |
| clientcare@ | 2 | ||
| dhill@ | 2 | ||
| etaylor@ | 1 | ||
| deltastar.com | 2 | 0.0 | new |
| dswhr@ | 1 | ||
| lchand@ | 1 | ||
| fairscreen.com | 2 | 0.2 | +700% |
| shannon@ | 1 | ||
| support@ | 1 | ||
| argusverify.com | 2 | 0.8 | +167% |
| eric@ | 1 | ||
| larissa@ | 1 | ||
| viewhouse.com | 1 | 0.0 | new |
| hr@ | 1 | ||
| sierrausd.org | 1 | 0.0 | new |
| hwade@ | 1 | ||
| lotuscmc.com | 1 | 0.0 | new |
| megan@ | 1 |
🏷️ Tags applied
Computed from the store, not inferred.
- 12Escalated
- 7provided_contact_info
- 6linear_ticket_pending
- 1response_with_verification_info
💬 Themes
Inferred: read from the ticket bodies, not computed.
SLA expiry is not firing, so clients chase us to close their own orders
Seven tickets from one client asking us to close orders that had already run past their SLA. The pattern is always the same: attempts stop, the order sits open, and the client notices before we do.
- 20550 seven emails to one applicant over eight days, never expired
- 20551 two references whose email bounced on the first attempt, still open days later
- 20630 did not close because emails do not count as attempts when calls are enabled and there was no viable phone number
- 20712 two files past a 3-day SLA, closed only on request
- 20722 closed as expired on our side, still showing dispatched on theirs
- 20765 three attempts complete, should have closed the day before
- 20769 applicant uploaded documents mid-SLA and the order still did not close
Work we completed is not visible on the client's side
Five tickets where the verification was done and the client could not see it, so they re-opened the question. Two of them are the same order reaching two different people at the client.
- 20549 results never synced to TAZ, refreshed manually
- 20715 our call attempts land in a field the client's own clients cannot see, so the work looks undone
- 20722 manual sync failed the first time and had to be repeated
- 20746 closed as third-party verifier with the reason visible to us and not to them
- 20749 the same order, asked again by a second person at the same client
Dates we report are wrong often enough to cause reinvestigations
Four tickets in one week, and a wrong date is the one error that comes back as a dispute rather than a question.
- 20395 hire date impossible against the applicant's date of birth, verifier had mistyped it
- 20412 the same file's verifier confirming they meant 2024, not 2014
- 20662 National Guard dates contradicted the applicant's own documents; client headed off a reinvestigation
- 20714 a start date we sent as 2026-05-11 displayed on their end as 5 November
Parchment runs without the client's approval, then stalls with no fallback
Four tickets. One client was billed for third-party reports they had not approved, twice, and nobody has a plan for a Parchment order that never returns.
- 20606 contact information the client supplied could not be used because a Parchment request was pending
- 20628 three days of "still pending" and no answer beyond that
- 20809 Parchment ordered without fee approval, then a second one; client asking for per-client blueprints
- 20819 client points out they would call the school directly; we do not
An invalid contact stops an order instead of escalating it
Five tickets where the only contact was bad and nothing routed the order to research. The expected behaviour is a flag for manual contact research.
- 20454 dispatched 31 July, no attempt of any kind made for ten days
- 20629 none@none.com detected and removed, then nothing
- 20713 three references with undeliverable or placeholder addresses
- 20766 two more, one of them an address at the applicant's own employer
- 20768 never flagged as no-valid-contact, and the research note explaining why no call was made never reached the client
The inbound call path drops work it has already done
Three tickets where a verifier did speak to us and the result did not survive.
A phishing email impersonated a client
Two tickets on the same attempt: a forged Adobe Sign request for a "vendor contract" sent in a client's name. Robin asked whether it was genuine instead of opening it, and the client confirmed it was not theirs.
🌟 PRAISE
Client praise, in their words.
No noteworthy praise this week.