🎧 Customer Support report
Mon 9/7/26 to Sun 9/13/26
Report generated: Mon 9/21/26 @ 10:27pm 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 9/07 | 1 | 1 | 0 | 0 | 0 | 0 |
| Tue 9/08 | 71 | 16 | 14 | 15 | 1 | 0 |
| Wed 9/09 | 59 | 28 | 3 | 11 | 7 | 0 |
| Thu 9/10 | 39 | 21 | 2 | 2 | 2 | 1 |
| Fri 9/11 | 32 | 17 | 2 | 5 | 1 | 0 |
| Sat 9/12 | 0 | 0 | 0 | 0 | 0 | 0 |
| Sun 9/13 | 0 | 0 | 0 | 0 | 0 | 0 |
Business hours only. Rows do not sum to messages in: 53 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
9 messages are waiting on a reply. Longest first.
🔇 Bad closes
117 of 117 closed threads judged: 104 answered, 2 bad closes, 11 not a support request.
❌ We never replied (2)
22556firstpointresources.com
Client reported an applicant complaint that we called someone who says they never authorised a verification, and asked us to investigate; we never replied.
We received a complaint from an applicant when we called to verify their employment- turns out they own the company we called. They were confused, and claimed they weren't applying for anything.
22277smarthrcheqs.com
Client asked us to provide the information for a completed professional reference search and we never replied at all.
it appears the reference, Rina Evans, completed the request. Can you please provide the information for this search?
📈 Against your own baseline
| This week | 4w baseline | ||
|---|---|---|---|
| Tickets in | 123 ↑ | 69 | +79% |
| Messages in | 202 ↑ | 107 | +88% |
| Closed | 117 ↑ | 67 | +75% |
| Still open | 6 | – | |
| Median response | 38m | 41m | flat |
| p90 response | 3.8h ↓ | 4.4h | 🟢 -14% 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 | 39m | half were faster |
| p75 | 1.9h | |
| p90 | 3.9h | 10% waited longer than this |
| p95 | 6.3h | |
| p99 | 3.9d | 1% waited longer |
| max | 20.2d |
| Answered | Messages | Share |
|---|---|---|
| < 1 business hour | 292 | 60% |
| < 4 hours | 444 | 91% |
| < 1 business day | 471 | 96% |
| < 3 business days | 481 | 98% |
| > 7 business days | 4 | 0.8% |
489 inbound messages over the trailing 4 weeks. A single week is too few messages for a p99 to mean anything.
⚡ What changed
- Inbound messages up 88% on the 4-week baseline (202 against 107).
- 6 tickets have been waiting on a reply for more than 7 business days, the longest 38.7d.
🔍 DIAGNOSIS
Why, and who it is coming from.
⏳ Where the time goes
57.3d of business time across 123 tickets, 58% of it waiting on us.
| Owed by | Hours | Share |
|---|---|---|
| Us | 33.5d | 58% |
| The client | 23.8d | 42% |
| Our time per ticket | ||
|---|---|---|
| p50 | 1.1h | half held us less |
| p90 | 5.1h | the tail that sets the week |
| max | 20.0h |
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 | 30 | 15.8 | +90% |
| vsquality@ | 23 | ||
| verification@ | 4 | ||
| michaelvelasco@ | 1 | ||
| 3rddegreescreening.com | 15 | 2.5 | +500% |
| jimmy.waters@ | 15 | ||
| srascreening.com | 17 | 9.0 | +89% |
| vmartsinyuk@ | 4 | ||
| ckranz@ | 3 | ||
| cgajjar@ | 3 | ||
| smarthrcheqs.com | 6 | 0.2 | +2300% |
| gfontanelli@ | 4 | ||
| ccogdill@ | 2 | ||
| truviewbsi.com | 4 | 0.8 | +433% |
| jtincher@ | 2 | ||
| jmorales@ | 2 | ||
| firstchoicebackground.com | 20 | 17.5 | +14% |
| samanthad@ | 9 | ||
| kennia@ | 8 | ||
| courtney@ | 2 | ||
| advrep.com | 5 | 3.0 | +67% |
| ryarbrough@ | 3 | ||
| verifications@ | 2 | ||
| wmchs.net | 2 | 0.0 | new |
| office@ | 1 | ||
| mrscoppess@ | 1 |
🏷️ Tags applied
Computed from the store, not inferred.
- 15Escalated
- 6not_sure_if_received_09/08
- 6provided_contact_info
- 4Robin_review
- 3dispute
- 1linear_ticket_pending
- 13rd_Party_Verifier
💬 Themes
Inferred: read from the ticket bodies, not computed.
Results stopped syncing to clients' systems
The week's dominant cost by a wide margin. Work was completed here and stayed invisible there, so clients spent the week asking us for answers we already had, and one of them started doubting their own dispatch counts.
- 22427 First Choice orders being worked with no vendor notes syncing, opened as CORE-609 and synced by hand
- 22223 client flagging 210 searches showing dispatched and asking whether it was a sync issue
- 22254 order closed as expired on Friday, still showing actively dispatched
- 22213 "no attempts since 08/28" on an order completed 08/31
- 22222 reference completed 09/04, still showing New Dispatched
- 22233 order expired 09/04 with the attempts never reaching the client
- 22225 completed 08/25, still pending on their side two weeks later
- 22231 client's CEO writing in directly for a reference that never synced
- 22430 reference answered by email, results never reached TAZ
- 22297 vendor notes showed complete, responses never arrived
- 22275 employer completed the request, file never completed on our side either
- 22264 client chasing a search last touched 09/01
Orders not closing when their SLA ran out, and SLAs nobody knew they had
Two clients spent the week discovering their own configuration. One found employment orders on a 30-day blueprint they had never asked for; the other has been chasing the same expiry bug since early August.
- 19977 Veritable's fourth example since 8/03, two Linear issues deep, failed calls not counting as attempts
- 22286 3rd Degree escalating a batch that should have expired, one order stuck looping on a false self-employment detection
- 22284 client learning their employment orders sit on a 30-day SLA, asking for all of them at 5 days
- 22451 our fix over-applied at 8pm, client re-dispatching orders we closed early
- 22388 order the client believed was document-only closed as third-party verifier
- 22300 reference past SLA, closed only when the client asked
Parchment cancellations arriving with no reason attached
Same client, five times in a week, asking the same question: why was it cancelled, and can we have the report. Two Linear issues opened; the answers when they came were useful, which is the point.
- 22314 client explaining they do not close a search without the Parchment response, then sent the wrong candidate's file
- 22332 three cancellations chased, two answered against the wrong schools on the first pass
- 22294 cancellation reason existed and was useful, graduates pre-2019 are not in Parchment
- 22457 client supplying an example of what good looks like, a completed no-record report
- 22568 same question again on another school
- 22502 Parchment fee missing from the returned report, answer was zero
- 22478 same, another file, also zero
Verifications accepted from sources that do not hold up
Five tickets where we returned an answer and the client had to tell us it was not a usable one. These are the expensive ones: the report went out.
- 22201 employment verified by a former employee, credited and redispatched
- 22443 hire date returned identical to the applicant's date of birth
- 22398 only the current role captured when the applicant claimed two prior periods
- 22447 verifier told the client she never answered "no", our record says she did
- 22450 two orders, same employer, same verifier, opposite answers
The AI agent not finishing the call it answered
Four tickets where an inbound call was taken and something was lost.
- 22493 references confirmed they answered, orders closed as not completed, and one question never asked
- 22382 inbound calls received but never mapped to their orders, completed by hand
- 22256 rehire question returned as empty quotation marks
- 22266 school spoke to our AI agent, then had to send the same answer twice more
Applicants who could not upload their documents
Three tickets and two named applicants blocked, with converting the file to JPEG as the only workaround anyone found.
The wrong party contacted
Four tickets, including one that reached the applicant himself.
- 22556 applicant complained he had not authorised anything after we called his own business
- 22204 wrong company verified and reported, then the same bad contact survived the redispatch
- 22428 Truv report for a different employer, and a document-only SLA closes rather than asking the applicant
- 22367 contacts we used and contacts the client saw did not match, traced to their own copy-paste
🌟 PRAISE
Client praise, in their words.
No noteworthy praise this week.