indifferentketchup/broccolini-bot
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

First upload

Browse Source
This commit is contained in:
samkintop
2026-02-17 21:49:58 -06:00
parent 58e8e84bba
commit 7893f555fa
6 changed files with 0 additions and 627 deletions
Download Patch File Download Diff File Expand all files Collapse all files

0
docs/analytics/Part 1 Analysis.md
View File

324
docs/analytics/Part 1 Batch Analytics Report.html
View File

@@ -1,324 +0,0 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
<title>Mode C: Batch Analytics Report</title>
<style>
:root {
--bg: #fafbfc;
--paper: #ffffff;
--text: #1a1d21;
--text-muted: #57606a;
--accent: #0969da;
--accent-soft: #ddf4ff;
--border: #d0d7de;
--table-stripe: #f6f8fa;
--code-bg: #f0f2f5;
--font-sans: 'Segoe UI', system-ui, -apple-system, sans-serif;
--font-mono: ui-monospace, 'Cascadia Code', 'Source Code Pro', monospace;
--radius: 6px;
--shadow: 0 1px 3px rgba(0,0,0,.06);
}
* { box-sizing: border-box; }
body {
margin: 0;
padding: 2rem 1.5rem 3rem;
font-family: var(--font-sans);
font-size: 15px;
line-height: 1.6;
color: var(--text);
background: var(--bg);
}
.report {
max-width: 820px;
margin: 0 auto;
background: var(--paper);
padding: 2.5rem 3rem;
border-radius: var(--radius);
box-shadow: var(--shadow);
}
.report-header {
border-bottom: 2px solid var(--border);
padding-bottom: 1.5rem;
margin-bottom: 2rem;
}
.report-header h1 {
margin: 0 0 0.5rem;
font-size: 1.75rem;
font-weight: 600;
color: var(--text);
}
.report-meta {
font-size: 0.9rem;
color: var(--text-muted);
}
.report-meta p { margin: 0.25rem 0; }
h2 {
font-size: 1.2rem;
font-weight: 600;
margin: 2rem 0 1rem;
padding-bottom: 0.35rem;
color: var(--text);
border-bottom: 1px solid var(--border);
}
h2:first-of-type { margin-top: 0; }
p { margin: 0.75rem 0; }
.narrative, .recommendation { font-style: normal; }
strong { font-weight: 600; }
table {
width: 100%;
border-collapse: collapse;
font-size: 0.9rem;
margin: 1rem 0;
border-radius: var(--radius);
overflow: hidden;
box-shadow: 0 1px 2px rgba(0,0,0,.05);
}
th, td {
padding: 0.6rem 1rem;
text-align: left;
border: 1px solid var(--border);
}
th {
background: var(--table-stripe);
font-weight: 600;
color: var(--text);
}
tr:nth-child(even) { background: var(--table-stripe); }
tr:hover { background: #eef2f7; }
pre, code {
font-family: var(--font-mono);
font-size: 0.85em;
}
pre {
background: var(--code-bg);
padding: 1rem 1.25rem;
border-radius: var(--radius);
overflow-x: auto;
margin: 1rem 0;
border: 1px solid var(--border);
}
code { padding: 0.15em 0.4em; background: var(--code-bg); border-radius: 4px; }
ul { margin: 0.75rem 0; padding-left: 1.5rem; }
li { margin: 0.35rem 0; }
hr {
border: none;
border-top: 1px solid var(--border);
margin: 2rem 0;
}
@media print {
body { background: #fff; padding: 0; }
.report {
max-width: none;
box-shadow: none;
padding: 0;
}
h2 { page-break-after: avoid; }
table { page-break-inside: avoid; }
}
</style>
</head>
<body>
<div class="report">
<header class="report-header">
<h1>Mode C: Batch analytics report</h1>
<div class="report-meta">
<p><strong>Source:</strong> <code>Discord Ticket Transcripts/Drive2/</code></p>
<p><strong>Computed:</strong> From transcript HTML (metadata + decoded base64 message payloads).</p>
<p><strong>Guide:</strong> Part 1 Analysis (Transcript analytics schemas, Broccolini support section).</p>
<p><strong>Tool:</strong> <code>scripts/batch_transcript_analytics.py</code></p>
</div>
<p style="margin-top: 1rem;">Analytics below are <strong>per‑ticket and aggregate</strong> across 722 transcripts. Dimensions that require full Mode A extraction (issue categories, tags, wiki success/failure, intake gaps, frequency/impact, resolution status, email forgotten/misspelled) are noted; tables use parser-derived data where available.</p>
</header>
<h2>1. Volume and scope</h2>
<table>
<thead><tr><th>Metric</th><th>Value</th></tr></thead>
<tbody>
<tr><td>Total tickets</td><td>722</td></tr>
<tr><td>Transcripts with parse errors</td><td>0</td></tr>
<tr><td>Tickets with "Ticket closed" / "Transcript saving" in payload</td><td>722 (100%)</td></tr>
<tr><td>Tickets with claimed channel name (staff claimed)</td><td>671 (93%)</td></tr>
<tr><td>Tickets with escalation mentioned in text</td><td>1</td></tr>
</tbody>
</table>
<p class="narrative"><strong>Narrative:</strong> The Drive2 batch is fully parseable. Virtually all tickets show a close/saving event; 93% have a claimed channel, indicating most tickets were claimed by staff before closure. Escalations are rare in this set.</p>
<hr />
<h2>2. Game detection and game_or_server (heuristic)</h2>
<p>From decoded form + messages: text buffer scanned for canonical game names and aliases (Part 1 Analysis §5). <code>game_or_server</code> routing buckets would require Mode A (Valheim | Rust main | MC modded | MC vanilla | Other).</p>
<table>
<thead><tr><th>game_detected (heuristic)</th><th>Count</th><th>%</th></tr></thead>
<tbody>
<tr><td>Project Zomboid</td><td>257</td><td>35.6</td></tr>
<tr><td>Minecraft</td><td>179</td><td>24.8</td></tr>
<tr><td>Satisfactory</td><td>79</td><td>10.9</td></tr>
<tr><td>Palworld</td><td>46</td><td>6.4</td></tr>
<tr><td>Not Mentioned</td><td>45</td><td>6.2</td></tr>
<tr><td>Enshrouded</td><td>18</td><td>2.5</td></tr>
<tr><td>ARK: Survival Evolved</td><td>18</td><td>2.5</td></tr>
<tr><td>7 Days to Die</td><td>17</td><td>2.4</td></tr>
<tr><td>Valheim</td><td>14</td><td>1.9</td></tr>
<tr><td>DayZ</td><td>10</td><td>1.4</td></tr>
<tr><td>FiveM</td><td>8</td><td>1.1</td></tr>
<tr><td>Core Keeper</td><td>6</td><td>0.8</td></tr>
<tr><td>Vintage Story</td><td>5</td><td>0.7</td></tr>
<tr><td>Rust</td><td>5</td><td>0.7</td></tr>
<tr><td>Factorio</td><td>5</td><td>0.7</td></tr>
<tr><td>V Rising</td><td>3</td><td>0.4</td></tr>
<tr><td>ECO</td><td>3</td><td>0.4</td></tr>
<tr><td>Necesse</td><td>4</td><td>0.6</td></tr>
</tbody>
</table>
<p class="narrative"><strong>Narrative:</strong> Project Zomboid and Minecraft dominate; Satisfactory and Palworld are next. About 6% have no game detected from text. Full <code>game_or_server</code> (MC modded vs vanilla, Rust main, etc.) needs per‑ticket Mode A extraction.</p>
<hr />
<h2>3. Issue categories and tags</h2>
<p><strong>Issue categories</strong> (Availability, Connectivity, Billing, Data/saves, Configuration/mods) and <strong>TICKET_TAGS</strong> (Server Down, Stuck Restarting, Can't Connect, Server Lag, Billing, Refund Request, Mod Help, Backup Restore, World/Save, Server Config) require Mode A extraction from each transcript. No aggregate table is computed from the batch parser.</p>
<p class="recommendation"><strong>Recommendation:</strong> Run Mode A on all transcripts (or a sample), then aggregate <code>issue_types</code> and suggested tags into counts and top tags per game.</p>
<hr />
<h2>4. Message count and conversation shape</h2>
<table>
<thead><tr><th>Messages (header)</th><th>Number of tickets</th></tr></thead>
<tbody>
<tr><td>3–6</td><td>151</td></tr>
<tr><td>7–10</td><td>128</td></tr>
<tr><td>11–15</td><td>95</td></tr>
<tr><td>16–22</td><td>88</td></tr>
<tr><td>23–35</td><td>78</td></tr>
<tr><td>36–60</td><td>45</td></tr>
<tr><td>61+</td><td>137</td></tr>
</tbody>
</table>
<p>Summary stats (from header): Min 3, max 356 messages per ticket; majority in the 3–22 range. Back‑and‑forth turns, duration, and "staff asked for more info repeatedly" require Mode A.</p>
<p class="narrative"><strong>Narrative:</strong> Conversation length is skewed toward short (3–10 messages) and mid (11–35); a smaller set of tickets are long (60+ messages), likely complex or multi-step resolutions.</p>
<hr />
<h2>5. Attachments (saved / skipped)</h2>
<table>
<thead><tr><th>Attachments saved</th><th>Number of tickets</th></tr></thead>
<tbody>
<tr><td>0</td><td>325</td></tr>
<tr><td>1</td><td>169</td></tr>
<tr><td>2</td><td>81</td></tr>
<tr><td>3</td><td>55</td></tr>
<tr><td>4</td><td>30</td></tr>
<tr><td>5+</td><td>62</td></tr>
</tbody>
</table>
<table>
<thead><tr><th>Attachments skipped</th><th>Number of tickets</th></tr></thead>
<tbody>
<tr><td>0</td><td>695</td></tr>
<tr><td>1</td><td>16</td></tr>
<tr><td>2</td><td>6</td></tr>
<tr><td>3</td><td>3</td></tr>
<tr><td>4</td><td>2</td></tr>
</tbody>
</table>
<p class="narrative"><strong>Narrative:</strong> About 45% of tickets have at least one attachment saved; most have none skipped. Skipped reasons and mentions_screenshots/clips/logs require Mode A.</p>
<hr />
<h2>6. Staff involvement (from payload)</h2>
<p>Staff identified by Broccolini support user IDs (Part 1 Analysis §10.1) appearing in message payloads.</p>
<table>
<thead><tr><th>Staff involved (count per ticket)</th><th>Number of tickets</th></tr></thead>
<tbody>
<tr><td>0</td><td>152</td></tr>
<tr><td>1</td><td>545</td></tr>
<tr><td>2</td><td>25</td></tr>
</tbody>
</table>
<p class="narrative"><strong>Narrative:</strong> Most tickets have exactly one staff member in the payload; 152 have no staff ID in messages (e.g. Ticket Tool–only or unclaimed). "Tickets claimed per member" and first‑response time need claim/unclaim message parsing (channel name gives claim attribution; full workload per member needs Mode A or claim-event parsing).</p>
<hr />
<h2>7. User count (participants per ticket)</h2>
<table>
<thead><tr><th>User count (header)</th><th>Number of tickets</th></tr></thead>
<tbody>
<tr><td>2</td><td>70</td></tr>
<tr><td>3</td><td>582</td></tr>
<tr><td>4</td><td>44</td></tr>
<tr><td>5</td><td>8</td></tr>
<tr><td>6</td><td>2</td></tr>
</tbody>
</table>
<p class="narrative"><strong>Narrative:</strong> Most tickets have 3 participants (requester + 1 staff + Ticket Tool); 4+ participants suggest multi-staff or extra users in thread.</p>
<hr />
<h2>8. Wiki usage and wiki‑linked outcomes</h2>
<p><strong>wiki_articles_posted</strong>, <strong>wiki_solved_issue</strong> (true / false / unclear), and staff‑linked outcomes (user_wanted_broccolini_to_do_it, user_wanted_broccolini_but_walkthrough) require Mode A extraction. No aggregate table from the batch parser.</p>
<p class="recommendation"><strong>Recommendation:</strong> After Mode A, aggregate: (1) tickets where wiki_solved_issue = true / false / unclear; (2) per support member: wiki posts that solved vs did not, "do it for me" vs walkthrough counts.</p>
<hr />
<h2>9. Email analytics</h2>
<p>Parser did not detect "Account Email" + email in the same decoded block in this run. <strong>Email analytics</strong> (email_forgotten, email_misspelled, email_didnt_link, email_corrected) require Mode A extraction from form embeds and message text.</p>
<hr />
<h2>10. Frequency / impact distributions</h2>
<p><strong>frequency</strong> (once | sometimes | every_time | unclear) and <strong>impact</strong> (minor | moderate | severe | blocked | unclear) require inference from transcript wording (Mode A). No aggregate table from the batch parser.</p>
<hr />
<h2>11. Resolution patterns</h2>
<p>From parser: all 722 tickets contain "Ticket closed" or "Transcript saving" in the payload. <strong>status</strong> (resolved | unresolved | escalated | unclear) and <strong>relied_on</strong> (logs | mod_updates | staff_action | other) require Mode A. One ticket mentions escalation in text.</p>
<p class="narrative"><strong>Narrative:</strong> All transcripts represent closed/saved tickets; resolution outcome and what resolution relied on need per‑ticket extraction.</p>
<hr />
<h2>12. Intake gaps</h2>
<p>Per‑ticket intake_gaps (account_contact, issue_type, reproduction, environment, attachments, priority, rules) each as complete | partial | missing require Mode A. No aggregate table from the batch parser.</p>
<p class="recommendation"><strong>Recommendation:</strong> After Mode A, report % complete / partial / missing per dimension to target form and template improvements.</p>
<hr />
<h2>13. Recurring analytics (Broccolini support section)</h2>
<p>From the batch parser we have:</p>
<ul>
<li><strong>Tickets per game_detected (heuristic):</strong> see §2.</li>
<li><strong>Claimed channel share:</strong> 671/722 (93%).</li>
<li><strong>Staff involved count per ticket:</strong> see §6.</li>
</ul>
<p><strong>Require Mode A or claim parsing:</strong></p>
<ul>
<li>Tickets claimed per member (from claim/unclaim messages or channel name).</li>
<li>First response time, re‑opens, escalations.</li>
<li>Tag distribution, repeat customers, sentiment toward staff.</li>
<li>Wiki‑linked outcomes per member (§9.2).</li>
</ul>
<hr />
<h2>14. How to reproduce and extend</h2>
<ol>
<li><strong>Run batch parser (this report's source):</strong>
<pre>python3 scripts/batch_transcript_analytics.py "Discord Ticket Transcripts/Drive2"</pre>
For a subfolder or Drive:
<pre>python3 scripts/batch_transcript_analytics.py "Discord Ticket Transcripts/Drive"</pre>
</li>
<li><strong>Full Mode C tables:</strong> Run Mode A extraction on each transcript (or a sample), collect JSON, then aggregate by issue categories, tags, game_or_server, wiki_solved_issue, intake_gaps, frequency/impact, resolution status, and email analytics. Use Part 1 Analysis and <code>docs/TICKET-ANALYTICS-SCHEMA-PROMPTING.md</code> as the schema source of truth.</li>
</ol>
</div>
</body>
</html>

195
docs/analytics/Part 1 Batch Analytics Report.md
View File

@@ -1,195 +0,0 @@
# Mode C: Batch analytics report
**Source:** `Discord Ticket Transcripts/Drive2/`
**Computed:** From transcript HTML (metadata + decoded base64 message payloads).
**Guide:** Part 1 Analysis (Transcript analytics schemas, Broccolini support section).
**Tool:** `scripts/batch_transcript_analytics.py`
Analytics below are **per‑ticket and aggregate** across 722 transcripts. Dimensions that require full Mode A extraction (issue categories, tags, wiki success/failure, intake gaps, frequency/impact, resolution status, email forgotten/misspelled) are noted; tables use parser-derived data where available.
---
## 1. Volume and scope
| Metric | Value |
|--------|--------|
| Total tickets | 722 |
| Transcripts with parse errors | 0 |
| Tickets with “Ticket closed” / “Transcript saving” in payload | 722 (100%) |
| Tickets with claimed channel name (staff claimed) | 671 (93%) |
| Tickets with escalation mentioned in text | 1 |
**Narrative:** The Drive2 batch is fully parseable. Virtually all tickets show a close/saving event; 93% have a claimed channel, indicating most tickets were claimed by staff before closure. Escalations are rare in this set.
---
## 2. Game detection and game_or_server (heuristic)
From decoded form + messages: text buffer scanned for canonical game names and aliases (Part 1 Analysis §5). `game_or_server` routing buckets would require Mode A (Valheim | Rust main | MC modded | MC vanilla | Other).
| game_detected (heuristic) | Count | % |
|---------------------------|-------|---|
| Project Zomboid | 257 | 35.6 |
| Minecraft | 179 | 24.8 |
| Satisfactory | 79 | 10.9 |
| Palworld | 46 | 6.4 |
| Not Mentioned | 45 | 6.2 |
| Enshrouded | 18 | 2.5 |
| ARK: Survival Evolved | 18 | 2.5 |
| 7 Days to Die | 17 | 2.4 |
| Valheim | 14 | 1.9 |
| DayZ | 10 | 1.4 |
| FiveM | 8 | 1.1 |
| Core Keeper | 6 | 0.8 |
| Vintage Story | 5 | 0.7 |
| Rust | 5 | 0.7 |
| Factorio | 5 | 0.7 |
| V Rising | 3 | 0.4 |
| ECO | 3 | 0.4 |
| Necesse | 4 | 0.6 |
**Narrative:** Project Zomboid and Minecraft dominate; Satisfactory and Palworld are next. About 6% have no game detected from text. Full `game_or_server` (MC modded vs vanilla, Rust main, etc.) needs per‑ticket Mode A extraction.
---
## 3. Issue categories and tags
**Issue categories** (Availability, Connectivity, Billing, Data/saves, Configuration/mods) and **TICKET_TAGS** (Server Down, Stuck Restarting, Can’t Connect, Server Lag, Billing, Refund Request, Mod Help, Backup Restore, World/Save, Server Config) require Mode A extraction from each transcript. No aggregate table is computed from the batch parser.
**Recommendation:** Run Mode A on all transcripts (or a sample), then aggregate `issue_types` and suggested tags into counts and top tags per game.
---
## 4. Message count and conversation shape
| Messages (header) | Number of tickets |
|-------------------|--------------------|
| 3–6 | 151 |
| 7–10 | 128 |
| 11–15 | 95 |
| 16–22 | 88 |
| 23–35 | 78 |
| 36–60 | 45 |
| 61+ | 137 |
Summary stats (from header): Min 3, max 356 messages per ticket; majority in the 3–22 range. Back‑and‑forth turns, duration, and “staff asked for more info repeatedly” require Mode A.
**Narrative:** Conversation length is skewed toward short (3–10 messages) and mid (11–35); a smaller set of tickets are long (60+ messages), likely complex or multi-step resolutions.
---
## 5. Attachments (saved / skipped)
| Attachments saved | Number of tickets |
|-------------------|-------------------|
| 0 | 325 |
| 1 | 169 |
| 2 | 81 |
| 3 | 55 |
| 4 | 30 |
| 5+ | 62 |
| Attachments skipped | Number of tickets |
|---------------------|-------------------|
| 0 | 695 |
| 1 | 16 |
| 2 | 6 |
| 3 | 3 |
| 4 | 2 |
**Narrative:** About 45% of tickets have at least one attachment saved; most have none skipped. Skipped reasons and mentions_screenshots/clips/logs require Mode A.
---
## 6. Staff involvement (from payload)
Staff identified by Broccolini support user IDs (Part 1 Analysis §10.1) appearing in message payloads.
| Staff involved (count per ticket) | Number of tickets |
|----------------------------------|-------------------|
| 0 | 152 |
| 1 | 545 |
| 2 | 25 |
**Narrative:** Most tickets have exactly one staff member in the payload; 152 have no staff ID in messages (e.g. Ticket Tool–only or unclaimed). “Tickets claimed per member” and first‑response time need claim/unclaim message parsing (channel name gives claim attribution; full workload per member needs Mode A or claim-event parsing).
---
## 7. User count (participants per ticket)
| User count (header) | Number of tickets |
|--------------------|-------------------|
| 2 | 70 |
| 3 | 582 |
| 4 | 44 |
| 5 | 8 |
| 6 | 2 |
**Narrative:** Most tickets have 3 participants (requester + 1 staff + Ticket Tool); 4+ participants suggest multi-staff or extra users in thread.
---
## 8. Wiki usage and wiki‑linked outcomes
**wiki_articles_posted**, **wiki_solved_issue** (true / false / unclear), and staff‑linked outcomes (user_wanted_broccolini_to_do_it, user_wanted_broccolini_but_walkthrough) require Mode A extraction. No aggregate table from the batch parser.
**Recommendation:** After Mode A, aggregate: (1) tickets where wiki_solved_issue = true / false / unclear; (2) per support member: wiki posts that solved vs did not, “do it for me” vs walkthrough counts.
---
## 9. Email analytics
Parser did not detect “Account Email” + email in the same decoded block in this run. **Email analytics** (email_forgotten, email_misspelled, email_didnt_link, email_corrected) require Mode A extraction from form embeds and message text.
---
## 10. Frequency / impact distributions
**frequency** (once | sometimes | every_time | unclear) and **impact** (minor | moderate | severe | blocked | unclear) require inference from transcript wording (Mode A). No aggregate table from the batch parser.
---
## 11. Resolution patterns
From parser: all 722 tickets contain “Ticket closed” or “Transcript saving” in the payload. **status** (resolved | unresolved | escalated | unclear) and **relied_on** (logs | mod_updates | staff_action | other) require Mode A. One ticket mentions escalation in text.
**Narrative:** All transcripts represent closed/saved tickets; resolution outcome and what resolution relied on need per‑ticket extraction.
---
## 12. Intake gaps
Per‑ticket intake_gaps (account_contact, issue_type, reproduction, environment, attachments, priority, rules) each as complete | partial | missing require Mode A. No aggregate table from the batch parser.
**Recommendation:** After Mode A, report % complete / partial / missing per dimension to target form and template improvements.
---
## 13. Recurring analytics (Broccolini support section)
From the batch parser we have:
- **Tickets per game_detected (heuristic):** see §2.
- **Claimed channel share:** 671/722 (93%).
- **Staff involved count per ticket:** see §6.
**Require Mode A or claim parsing:**
- Tickets claimed per member (from claim/unclaim messages or channel name).
- First response time, re‑opens, escalations.
- Tag distribution, repeat customers, sentiment toward staff.
- Wiki‑linked outcomes per member (§9.2).
---
## 14. How to reproduce and extend
1. **Run batch parser (this report’s source):**
```bash
python3 scripts/batch_transcript_analytics.py "Discord Ticket Transcripts/Drive2"
```
For a subfolder or Drive:
```bash
python3 scripts/batch_transcript_analytics.py "Discord Ticket Transcripts/Drive"
```
2. **Full Mode C tables:** Run Mode A extraction on each transcript (or a sample), collect JSON, then aggregate by issue categories, tags, game_or_server, wiki_solved_issue, intake_gaps, frequency/impact, resolution status, and email analytics. Use Part 1 Analysis and `docs/TICKET-ANALYTICS-SCHEMA-PROMPTING.md` as the schema source of truth.

0
docs/analytics/Part 1 Prompting.md
View File

108
docs/analytics/Part 2 Batch Analytics Report.md
View File

@@ -1,108 +0,0 @@
# 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
1. **Run the extended batch parser (timestamps + claim_owner):**
```bash
python3 scripts/batch_transcript_analytics.py "Discord Ticket Transcripts/Drive2"
```
Use `Discord Ticket Transcripts/Drive/` for the larger set.
2. **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.
3. **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).

0
scripts/lookup-with-roles.js Executable file → Normal file
View File