← All reports

🎧 Customer Support report

Mon 8/24/26 to Sun 8/30/26

Report generated: Mon 9/21/26 @ 10:24pm 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🔍 DIAGNOSIS🌟 PRAISE

❤️ HEALTH

Is the desk ok right now?

📊 Activity

DayMsgs in<1h1-2h2-4h4h+Waiting
Mon 8/2419103420
Tue 8/2523131120
Wed 8/261261210
Thu 8/271242410
Fri 8/2817104000
Sat 8/29000000
Sun 8/30110000

Business hours only. Rows do not sum to messages in: 12 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.

WaitingCompanySubject

🔇 Bad closes

⚠️ 47 of 56 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-31 --threads threads.md, read and judge them, then --verdicts verdicts.jsonl, then re-run this report.

9 of 56 closed threads judged: 3 answered, 2 bad closes, 4 not a support request.

❌ We never replied (1)

21529rentapplication.net

Client forwarded a billing question about a Command Investigations invoice; the only activity is an internal note asking whether to forward it to billing, and we never replied.

You've reached Rent Application's support, this is really a question for Argus Verify. I've cc'd the appropriate contact there to assist

❌ We replied and it missed (1)

21411advrep.com

Client asked us to re-confirm a hire date that came back identical to the applicant's date of birth; we answered a different question about applicant document emails three times across two follow-ups, and our own internal note says the reply does not make sense.

The hire date provided in the returned results is the same as the applicant's date of birth.

📈 Against your own baseline

This week4w baseline
Tickets in5659flat
Messages in84 ↓104-19%
Closed5658flat
Still open0
Median response38m43mflat
p90 response3.9h3.8hflat
Still waiting0

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
p5038mhalf were faster
p751.9h
p903.2h10% waited longer than this
p955.1h
p997.8d1% waited longer
max29.3d
AnsweredMessagesShare
< 1 business hour23360%
< 4 hours35992%
< 1 business day37997%
< 3 business days38498%
> 7 business days51.3%

391 inbound messages over the trailing 4 weeks. A single week is too few messages for a p99 to mean anything.

⚡ What changed

🔍 DIAGNOSIS

Why, and who it is coming from.

⏳ Where the time goes

65.4d of business time across 56 tickets, 26% of it waiting on us.

Owed byHoursShare
Us16.9d26%
The client48.5d74%
Our time per ticket
p5045mhalf held us less
p906.0hthe tail that sets the week
max3.8d
Our timeTheirsCompanySubject

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.

CompanyWeekBaselineChange
3rddegreescreening.com40.8+433%
keely@3
jimmy.waters@1
advrep.com52.2+122%
verifications@3
ryarbrough@1
emagee@1
srascreening.com97.2+24%
sorders@3
cgajjar@2
ckranz@2
rentapplication.net21.0+100%
support@2
sorenson.com10.0new
mwalton@1
smarthrcheqs.com10.0new
ccogdill@1
jdp.com10.0new
nimirasweet@1
gips.org10.0new
cperkins@1

🏷️ Tags applied

Computed from the store, not inferred.

💬 Themes

Inferred: read from the ticket bodies, not computed.

Parchment run without approval, or not run at all

Six tickets, the week's most expensive pattern because each one carries a fee the client did not authorise or a verification that never started.

Automated employment research returning the wrong answer

Five tickets where the automation answered and the answer was wrong, which is worse than not answering: the order closes and nobody looks again.

Work not visible to the client, or not done when they expected it

Five tickets that are all the same complaint in different words: the client cannot see that anything happened.

Verification questions asked inconsistently

Two long threads, eleven and nine messages, both spent establishing what should have been asked the first time.

SLA expiry and routing

Two tickets where the clock or the routing, not the work, was the complaint.

🌟 PRAISE

Client praise, in their words.

No noteworthy praise this week.

Written by a Claude Code routine. Not for distribution outside Argus.