Part 2 — Deep batch analytics report (Mode C, second‑order)

Source: Discord Ticket Transcripts/Drive2/ (722 transcripts).
Input: Parser-derived data from transcript HTML + decoded base64 payloads (timestamps, claim owner, game heuristic, attachments, staff involvement).
Guides: Part 1 Analysis (schemas), Part 2 Analysis (batch dimensions), Part 1 Batch Analytics Report (structure).
Tool: scripts/batch_transcript_analytics.py (extended with timestamps and claim_owner).

This report focuses on patterns, bottlenecks, and recommendations rather than raw counts. Dimensions that require Mode A per‑ticket JSON (issue_types, tags, resolution.status, intake_gaps, wiki_solved_issue, frequency/impact, discord_handle) are called out; tables use parser-derived data where available and note where full analysis needs extraction.

1. Trends and anomalies over time

Period (UTC month)	Tickets	% of total
2025-09	7	1.0
2025-10	288	39.9
2025-11	427	59.1

Game mix over time (parser heuristic; full trend needs Mode A):
From Part 1 report, top games in the batch are Project Zomboid (35.6%), Minecraft (24.8%), Satisfactory (10.9%), Palworld (6.4%). No per‑month game breakdown was computed; recommend running Mode A and grouping by first_message_ts (or time.created) and issue.game_detected to detect spikes (e.g. Palworld post‑launch, MC modpack updates).

Narrative: Volume rises sharply from September to November (7 → 288 → 427). The jump suggests either growth in support load or a change in transcript export coverage. To interpret seasonality, spikes by game, or resolution.status over time, add Mode A extraction and bucket by week/month; then cross-tab with issue_types, game_detected, and tags to spot clusters (e.g. connectivity spikes for a specific game or platform).

2. Where tickets get stuck (bottlenecks)

Bottleneck	Count	% of 722	Notes
No staff ID in message payload	152	21.1	Ticket Tool–only or unclaimed; no Broccolini author in payload.
No attachments saved	325	45.0	Diagnostic quality unknown; mentions_logs/screenshots need Mode A.
Unclaimed (no claim_owner in channel name)	187	25.9	Channel not in staff-claimed-* format.
Long threads (60+ messages)	55	7.6	Likely complex or multi-step; good candidates for playbook review.
Escalation mentioned in text	1	0.1	Rare in this set.

Narrative: About one in five tickets have no staff author in the payload (either unclaimed or structural); a quarter show no claim in the channel name. Nearly half have zero attachments saved—correlating with resolution.status and intake_gaps.attachments (Mode A) would show whether missing diagnostics lengthen resolution or increase unresolved/escalated rates. Long threads (60+ messages) are a small but important slice; recommend tagging these and reviewing for missing reproduction steps, repeated “need more info,” or unclear priority so forms and macros can be improved.

3. Wiki and self‑service leverage

Dimension	Parser-derived	Mode A required
Wiki articles posted	—	`staff_and_wiki.wiki_articles_posted`
wiki_solved_issue (true/false/unclear)	—	Per ticket, then % by game_detected, issue_types
“Do it for me” vs walkthrough	—	`user_wanted_broccolini_to_do_it`, `user_wanted_broccolini_but_walkthrough` per member

Narrative: Wiki usage and outcomes cannot be computed from the current parser. With Mode A JSON, build: (1) top wiki slugs by usage and by game_detected/issue_types; (2) wiki_solved_issue rate per article and per game/issue slice; (3) per‑member counts for “do it for me” vs “walkthrough.” Use that to find topics where users often want staff to “do it” and either add or improve wiki steps and macros so more tickets can be resolved via self‑service. Recommend a short table per major wiki category (e.g. connectivity, backups, mods) with usage, success rate, and suggested new or updated pages.

4. Staff‑level patterns and opportunities

Member (claim_owner from channel)	Tickets claimed	% of claimed	Notes
indifferentchicken	407	76.0	Majority of claimed tickets in this batch.
indifferentketchup	128	24.0	Second by volume.
indifferentbroccoli, indifferentcat, indifferentstone	0 (in channel name)	—	No claims in this export with their channel prefix.

Staff involved in payload (any message): 545 tickets have exactly one staff ID in payload, 25 have two, 152 have zero (see §2). Claim count above is from channel name only; staff_involved from payload can include secondary participants.

Narrative: indifferentchicken carries most of the claimed load (76%); indifferentketchup handles the rest. The other three Broccolini members do not appear as claim_owner in this channel-name set—they may be in other panels, or claims may use different naming. To get full workload, resolution rate, escalation rate, first-response time, and wiki success per member, use Mode A plus claim/unclaim message parsing. Recommendations: (1) Cross-check with Discord/Ticket Tool to ensure all support members’ claim patterns are visible; (2) use Mode A to compute tickets resolved per member and escalation rate per member; (3) if one member remains disproportionately loaded, consider routing or documentation so common game/issue combinations can be handled by others or by wiki/macros.

5. Repeat customers and recurring problems

Dimension	Parser-derived	Mode A required
Tickets per requester	—	`account.discord_handle` or user ID; group by requester, count tickets.
Repeat customers (2+ tickets)	—	Same; filter count ≥ 2.
Cluster by game, issue_types, mods, errors	—	Per-ticket issue_types, reproduction.error_messages, environment.mods, game_detected.

Narrative: Requester identity is not in the parser output; repeat customers and recurring problems need Mode A (account.discord_handle, issue, reproduction, environment). With Mode A: (1) list requesters with 2+ tickets and their ticket IDs; (2) for each, cluster by game_detected, issue_types, mods, and error_messages to see if the same problem recurs or different games/issues; (3) suggest proactive actions—e.g. new guides for frequent error clusters, default configs or form questions for common mod/platform combos, or targeted announcements for repeat customers with the same issue type.

6. Design and process changes (recommendations)

Area	Finding (from this report)	Recommended change
Forms / bot questions	45% of tickets have 0 attachments saved; intake_gaps unknown without Mode A.	After Mode A: if intake_gaps.reproduction or intake_gaps.attachments are often missing for high-impact or long-thread tickets, add required reproduction steps and “attach logs/screenshot” for selected issue types or tags.
Wiki coverage	Wiki usage/success by game and issue not computable from parser.	After Mode A: identify top issue_types and game_detected with low wiki_solved_issue or high “do it for me”; add or update wiki pages and link them in macros.
Tagging / routing	issue_types and tags require Mode A.	After Mode A: define routing rules for high-impact or high-volume game+issue combinations (e.g. Palworld connectivity → specific wiki + optional escalation path).
Staff playbooks / macros	Long threads (60+ messages) and 152 tickets with no staff in payload suggest some tickets stall or lack clear handoff.	(1) Add a macro or playbook for “request logs/screenshots” when reproduction is missing; (2) encourage claiming so every ticket has an owner; (3) document common flows for top game+issue pairs (e.g. PZ config, MC mods) so response time and consistency improve.
Lifecycle visibility	No time to first response or time to resolution without Mode A timestamps.	Run Mode A; extract time.created, time.claimed, time.closed (or first/last message timestamps) to compute response and resolution times and re-opens, then tune SLAs and staffing.

Narrative: This batch surfaces claim imbalance (one member holding most claims), missing diagnostics (many tickets with no attachments saved), and unclaimed or no-staff-in-payload tickets. Full intake_gaps, resolution.status, and wiki outcomes depend on Mode A. Prioritise: (1) Mode A on a representative sample (or full set) to fill Tables 3, 5, and Part 1 report gaps; (2) form and bot changes for reproduction and attachments where gaps correlate with poor outcomes; (3) wiki and macro improvements where “do it for me” is high; (4) routing and playbooks for high-volume game+issue combinations and long-thread tickets.

7. How to reproduce and extend

Run the extended batch parser (timestamps + claim_owner):
```
python3 scripts/batch_transcript_analytics.py "Discord Ticket Transcripts/Drive2"
```
Use Discord Ticket Transcripts/Drive/ for the larger set.
Add Mode A extraction for full Part 2 analysis: run Mode A on each transcript (or sample), collect JSON, then:
- Bucket by time.created or first_message_ts for trends (issue_types, game_detected, resolution.status by week/month).
- Correlate intake_gaps with resolution time, unresolved/escalated rate, and back_and_forth_turns for bottlenecks.
- Aggregate wiki_solved_issue, wiki_articles_posted, and “do it” vs walkthrough for wiki & self‑service.
- Use claim/unclaim + resolution + wiki for staff profiles (workload, response time, wiki success, escalations).
- Group by account.discord_handle for repeat customers and cluster by game/issue/mod/error.
Schema and dimensions: Part 1 Analysis and docs/TICKET-ANALYTICS-SCHEMA-PROMPTING.md are the source of truth for fields; Part 2 Analysis defines the batch dimensions (§§2–12).

10 KiB Raw Blame History Unescape Escape