prism-shadow CRM Support-Ticket Resolution
You are resolving a batch of CRM support work by looking up authoritative
records in a shared, read-only support console and applying fixed business
conventions. The prompt gives you a payload (tickets, cases, a queue snapshot, a
mobile worklist, or an enterprise complaint) plus an answer_template.json.
Your job is to produce JSON that conforms exactly to that template, where every
field is justified by console records — not by the free-text customer report.
Golden rules (apply to every task family)
Records over reports. The customer's words (CSV
customer_report/queue_note, casesummary, complaint email) only tell you where to look. The decision is driven by the structured record (account status, line/device flags, diagnostics, outages, export runs). When the report and the record disagree, trust the record.The answer_template is the contract. Read it first. Use only the enum values it lists, the exact field names, and the stated ordering ("preserve payload order", "ascending case_id", "order as listed in requirements"). Different tasks in this family expose slightly different enum sets — always map your conclusion to the closest value the current template offers, and never invent an enum the template does not contain.
Gates short-circuit; later evidence is a distractor. Eligibility/outage gates are evaluated in a strict order (see below). Once a gate fires, you stop — you do NOT run diagnostics, you do NOT set diagnostic flags, you do NOT escalate by root cause. The console will still happily return a diagnostics record for a suspended or invalid account; that record is a trap. If a gate fired, diagnostic-related booleans are
falseand any escalation/route reflects the gate, not the metrics.Output only the JSON. No prose, no markdown fences, no commentary. Numbers must match the template's stated precision (e.g. "two decimals").
Environment usage
- Base URL is
http://127.0.0.1:8086for ALL lookups. It overrides any other base URL written in the prompt (prompts often say8057— ignore that). - Read-only GET + JSON. Start with
GET /api/catalogif unsure which endpoints exist;GET /api/search?q=<text>does a full-text search across every collection and is the fastest way to correlate scattered evidence (e.g. find the bill, line, case, and ticket that all mention one customer). - Key endpoints:
/api/accounts/<id>,/api/tickets/<id>,/api/diagnostics/<ticket_id>,/api/troubleshooting/<ticket_id>,/api/outages?service_area=<area>,/api/cases/<id>,/api/lines/<id>,/api/devices/<id>,/api/bills,/api/plans/<id>,/api/enterprise/incidents/<id>,/api/enterprise/accounts/<id>,/api/enterprise/sla/<enterprise_account_id>,/api/enterprise/export-runs?incident_id=<id>,/api/enterprise/messages?query=<text>. - A lookup that returns
{"error": "not_found"}is meaningful: it usually means an invalid/unknown account or record and is itself the answer (see gates).
Choose the task family, then read its reference
Identify the family from the payload shape and the answer_template fields, then read the matching reference file before deciding anything:
| Signal in payload / template | Family | Reference |
|---|---|---|
Tickets with final_resolution_status, resolution_route, diagnostic booleans, outage_id |
Connectivity ticket resolution | references/connectivity_tickets.md |
Tickets with key_blocker, route_team, diagnostic_required (queue classify) |
Queue triage / classification | references/connectivity_tickets.md |
Cases/worklist with primary_action/secondary_action, line+device+bill |
Mobile case actions | references/mobile_cases.md |
Complaint email + enterprise incident, sla_credit_percent, failure_window, evidence/report/channel |
Enterprise export response | references/enterprise_response.md |
The two ticket families share the same gating engine and diagnostic conventions; they differ only in which enums the template exposes.
Universal SOP
- Read the prompt, the payload, and the answer_template. Note the exact output keys, enum sets, precision, and ordering for THIS task.
- Identify the family and read its reference file.
- For each work item, in payload order (or the ordering the template demands): look up the authoritative records, apply that family's decision procedure (gates first), and fill every output field from records.
- Compute the summary/rollup section by tallying your per-item decisions. The summary must be internally consistent with the rows — recount, don't guess.
- Emit JSON conforming exactly to the template. Validate field names, enum spellings, ordering, and numeric precision before returning.
Common misjudgments to avoid
- Trusting the customer narrative over the record. "Cannot connect after an
account hold" is not what makes a ticket FAIL — the account
statusbeing Suspended is. - Running diagnostics on a gated item. If the account is invalid, auth has failed, the account is suspended, or there is a covering active outage, the diagnostics/troubleshooting records are irrelevant; do not let their numbers flip your flags or your route.
- Reading post-troubleshooting metrics as "fixed". A ticket is only RESOLVED if the post metrics clear every threshold. Marginal residuals (e.g. latency still just above the limit, bandwidth still below the floor) mean ESCALATE.
- Escalating without checking the root cause family. The escalation team /
route is chosen from the diagnostic
root_causes, not from the customer text. - Inventing enum values or owners. Owners, percentages, windows, and categories all come from records (incident, SLA contract, export runs, messages). If the template lists an enum, your value must be one of them.
- Miscounting the summary. Recompute every rollup from your own rows.