Two Contexts that turn a messy ticket into a classification, a next action, an escalation path, and QA notes. A starting point you shape with your own tiers, SLAs, and refund rules.
For support leads and QA reviewers standardising a tiered support queue.
Contexts
2
Support Lead, QA Reviewer
Guardrails
3
Do not promise refunds, credits, or policy exceptions unless the policy and ticket facts clearly support it., Escalate legal, safety, harassment, chargeback, or regulator-facing issues to a human instead of improvising a final answer., Do not invent account history, shipment status, or product decisions that are not present in the source systems.
How it works
Complex tickets are where a support team's consistency breaks. Two agents read the same case and one issues a credit while the other escalates. The cost shows up as inconsistent outcomes, slow handling times, and a QA process that argues after the fact.
Support Lead carries your tiers, escalation paths, SLAs, and refund rules, along with the promises agents are not allowed to make and the points where human approval is required. QA Reviewer turns that into response patterns, decision trees, QA checks, and escalation triggers, structured enough to plug into your tooling with classifications, next actions, and reviewer notes. The private instructions on each Context are where your policy lives, so the output reads like your team wrote it.
The same ticket gets the same handling on any desk. New starters get the decision tree instead of learning it from mistakes.
Run it with
oi support-lead+qa-reviewer classify this support ticket and return the next action, escalation path, response guidance, and QA notes
What's inside
Each context carries its own private instructions. Add yours and the setup answers the way your work actually runs.
Contexts
Our support operation has defined tiers, escalation paths, SLAs, and refund rules. The assistant needs to respect our tone of voice, compliance boundaries, and any promises AI agents are not allowed to make. It should understand when human approval is required and what systems support can reference.
Generate response patterns, decision trees, QA checks, and escalation triggers for complex tickets. The output should be structured enough to plug into support tooling with classifications, next actions, and reviewer notes.
Guardrails
Applied to every answer this setup gives.
Applied to every answer this setup gives.
Applied to every answer this setup gives.
Releases
Shipped the support starter with the policy, escalation, and QA restraints written in, so a complex ticket comes back classified with its next action and reviewer notes attached.
Maps a backyard vegetable garden from first bed to a maintenance rhythm you will actually keep. Works from your climate, plot size, sun hours, budget, and the private instructions on the Context. Never recommends a plant that is unsafe around pets.
Writes the scorecard and interview loop for a role before the first candidate goes through it. Works from the role level and mission, the must-have skills, and your private instructions. Never assesses a candidate on a trait nobody can observe.
Sorts a contract into must-fix points, negotiable items, and watchouts before the next round. Works from the contract text, your red lines, and the private instructions on each Context. Never treats its read of a clause as legal advice.
Get started
Run your last three escalations through it and compare the outcomes.
