Fewshot Attempt 01

SCN_003 CRM Support-Operations Resolution Skill

Executable SOP for resolving offline-ticket batches, mobile contact-center queues, and enterprise export-complaint response packages against the shared support console API. Follow the procedures literally — record fields are the source of truth, never assume values from the queue note or issue summary alone.

0. Environment & API map

Base URL (use this, not any 127.0.0.1 URL printed in a prompt): <remote-env-url>

Health: GET /health → {"ok": true} Catalog: GET /api/catalog (endpoint list + aggregate counts)

Empty body {} from diagnostics/troubleshooting = no record for that ticket.

A /api/diagnostics/<id> or /api/troubleshooting/<id> record may exist in the API even for a ticket that was gate-decided out (FAILED/PENDING_ACTION). Those records must NOT be used for issue-flag computation; they exist for the diagnostic_records_skipped_by_gate audit metric only.

1. Diagnostic floors (inferrable thresholds)

These absolute/ratio floors are NOT printed by the API; derive issue flags by comparing diagnostics metrics to these floors:

Inferred from gold-flag matching across the 5 diagnostic tickets whose post-troubleshooting status was known (TCK-5107 RESOLVED, TCK-5184 ESCALATED, TCK-5402 RESOLVED, TCK-5406 ESCOLATED, TCK-5407 ESCALATED):

• RESOLVED post metrics sit at/below floors: post lat 82 & 79 (≤100), post jit 21 & 18 (≤30), post bw 272/300=0.91 & 93/100=0.93 (≥0.80).
• ESCALATED post metrics still violate at least one floor; pre-troubleshooting metrics on every diagnostics-used ticket all violate the corresponding floor set.
• The bandwidth ratio 0.80 sits in the only weakly-constrained window (TCK-5107 pre 209/300=0.697 fails; TCK-5107 post 272/300=0.907 passes), so 80% is the best single round-number estimate.

Boundary rule: treat >= for floors below which there is no issue and > for floors above which there is an issue (strict inequalities; values do not hit the boundary in observed data).

2. Family A — Offline ticket batch resolution

Two output flavors exist; both follow the same gating + diagnosing + troubleshooting SOP. Distinguish by the answer template:

• Flavor-1 (full): ticket_decisions[] with final_resolution_status, diagnostic_needed, latency_issue, stability_issue, bandwidth_issue, outage_id, escalation_team, resolution_route; batch_summary has RESOLVED / PENDING_ACTION / ESCALATED / FAILED + tickets_requiring_customer_wait.
• Flavor-2 (queue-quality): ticket_decisions[] with final_resolution_status, route_team, key_blocker, diagnostic_required; queue_summary has per-team counts (TIER2_SUPPORT, FIELD_OPS, NETWORK_ENGINEERING, ACCOUNTS_PAYABLE) + per-status counts.

2.1 Gating order (apply strictly in this order; first hit wins)

For each ticket_id in the payload CSV (preserve payload order):

1. GET /api/accounts/<account_id>.
   • If the API returns {"error":"not_found"} or HTTP error → INVALID_ACCOUNT (key_blocker). final_resolution_status=FAILED, diagnostic_needed=false, all issue flags=false, escalation_team=NONE, route_team=NONE, outage_id="".
   • If account.authentication.last_login_status == "FAILURE" OR account.authentication.account_recovery_status == "FAILURE" → AUTH_FAILED. final_resolution_status=FAILED, diagnostic_needed=false, escalation_team=NONE, route_team=NONE, outage_id="".
   • If account.status == "Suspended":
     • Look at the line/ticket context (issue_summary or queue_note). If it mentions "overdue" (or the linked /api/lines/<line_id> shows suspension_reason=="OVERDUE_BILL", or there's a linked bill with status=="Overdue") → OVERDUE_SUSPENSION (FAILED, route_team= ACCOUNTS_PAYABLE, escalation_team=ACCOUNTS_PAYABLE, diagnostic_needed=false).
     • Otherwise (generic hold / non-billing suspension) → INELIGIBLE_ACCOUNT (FAILED, diagnostic_needed=false, escalation_team=NONE, route_team=NONE).
     • Fraud-suspension variant: if issue context says "fraud" → FRAUD_SUSPENSION (FAILED, route_team=NONE, diagnostic_needed=false). Field exists in enum; treat same as INELIGIBLE_ACCOUNT for team routing unless evidence says otherwise.
2. Account gate passed (Active + auth SUCCESS) → check outage. GET /api/outages?service_area=<ticket.service_area>. Consider an outage a match iff outage.active == true AND ticket.service_type in outage.service_types.
   • Match → ACTIVE_OUTAGE (key_blocker). final_resolution_status=PENDING_ACTION, diagnostic_needed=false, all issue flags=false, resolution_route=OUTAGE_WAIT, outage_id= (Flavor-1 only), route_team=NONE.
   • No match → proceed to diagnostics (diagnostic_needed=true).
3. Diagnostics route: GET /api/diagnostics/<ticket_id> and GET /api/troubleshooting/<ticket_id>.

2.2 Pre-troubleshooting issue flag evaluation

Flavor-1 tickets that ran diagnostics populate latency_issue, stability_issue, bandwidth_issue from diagnostics × floors:

• latency_issue = diagnostic.latency_ms > 100
• stability_issue = diagnostic.jitter_ms > 30
• bandwidth_issue = diagnostic.bandwidth_mbps < 0.80 × ticket.subscribed_mbps

(Flavor-2 does not emit per-issue flags but the underlying floors still drive the post-troubleshooting RESOLVED-vs-ESCALATED determination.)

2.3 Post-troubleshooting resolution determination

For each ticket that got diagnostics:

• Compute post-issue flags the same way against the troubleshooting record's post_ metrics:
  • post_latency_issue = troubleshooting.post_latency_ms > 100
  • post_stability_issue = troubleshooting.post_jitter_ms > 30
  • post_bandwidth_issue = troubleshooting.post_bandwidth_mbps < 0.80 × subscribed_mbps
• If ALL THREE post flags are false → RESOLVED via AUTO_TROUBLESHOOTING (final_resolution_status=RESOLVED, escalation_team=NONE, route_team=NONE, resolution_route=AUTO_TROUBLESHOOTING).
• If ANY post flag is true → ESCALATED (final_resolution_status=ESCALATED, resolution_route=ESCALATION). Escalation team comes from the root_causes of the diagnostics record (see §2.4).

Note RESOLVED/ESCALATED still preserve the original pre-troubleshooting issue flags in the Flavor-1 output (issue flags are PRE-TROUBLESHOOTING violations, not post).

2.4 Root-cause → escalation team map

For each ESCALATED ticket, take diagnostics.root_causes[] and map by keyword:

A ticket's key_blocker (Flavor-2) for ESCALATED tickets uses the root_cause text:

• BACKBONE_CAPACITY → key_blocker=NETWORK_CAPACITY
• PROVISIONING_STALE → key_blocker=PROVISIONING_STALE
• FIBER_DROP_DAMAGE or SIGNAL_LOSS → key_blocker=PHYSICAL_LINE_FAULT Other variants follow the same root_cause → team keyword pattern.

Evidence from gold:

• TCK-5184 root_causes=[FIBER_DROP_DAMAGE, SIGNAL_LOSS] both → FIELD_OPS ✓
• TCK-5406 root_causes=[BACKBONE_CAPACITY] → NETWORK_ENGINEERING ✓
• TCK-5407 root_causes=[PROVISIONING_STALE] → TIER2_SUPPORT ✓

2.5 Summary fields

Flavor-1 batch_summary:

• RESOLVED/PENDING_ACTION/ESCALATED/FAILED = counts of each final_resolution_status.
• tickets_requiring_customer_wait = count of PENDING_ACTION (waiting on outage).

Flavor-2 queue_summary:

• Per-status counts (FAILED, PENDING_ACTION, RESOLVED, ESCALATED).
• Per-team counts (TIER2_SUPPORT, FIELD_OPS, NETWORK_ENGINEERING, ACCOUNTS_PAYABLE) = counts of tickets routed to that team anywhere — including FAILED tickets routed to ACCOUNTS_PAYABLE via OVERDUE_SUSPENSION.

2.6 Field-emission cheat sheet

3. Family B — Mobile contact-center triage

Two output flavors:

• Flavor-1 (full): case_decisions[] with case_id, customer_id, line_id, primary_action, secondary_action, permission, bill_id, charge_amount_usd, final_route; queue_summary with self_service_fixes, billing_recoveries, carrier_updates, human_transfers.
• Flavor-2 (data-recovery analyst): case_decisions[] with case_id, primary_action, secondary_action, data_refuel_gb, charge_amount_usd, carrier_update_required, final_route; worklist_summary with data_refuel_cases, carrier_updates, device_setting_fixes, human_transfers, total_estimated_customer_charge_usd.

For every case_id in the payload (preserve ascending case_id order):

1. GET /api/cases/<case_id> → {customer_id, customer_location, device_id, line_id, issue_type, summary}.
2. GET /api/lines/<line_id> → {status, suspension_reason, roaming_enabled, data_used_gb, plan_id, device_id}.
3. GET /api/devices/<device_id> → settings (see decision tree).
4. GET /api/plans/<line.plan_id> → {data_limit_gb, data_refueling_price_per_gb} (only needed for REFUEL cases).
5. (Billing only) GET /api/bills, find bill where customer_id == case.customer_id and status == "Overdue" → use as the payment bill.

3.1 Mobile decision tree (first match wins, evaluate top-down)

Permission field semantics (Flavor-1 MMS):

• messaging_permissions.sms == false && storage == false → permission = "sms_and_storage"
• messaging_permissions.sms == false only → permission = "sms"
• messaging_permissions.storage == false only → permission = "storage"
• nothing missing → permission = "NONE" (shouldn't happen for a GRANT action)

Evidence mapping:

• CASE-2101: NO_SERVICE, home, line Active roaming true, sim_status=missing → RESEAT_SIM → SELF_SERVICE
• CASE-2102: NO_SERVICE, line.status=Suspended, suspension_reason=OVERDUE_BILL, customer ready → SEND_PAYMENT_REQUEST + RESUME_LINE_REBOOT, BILL-2102 amount=$86.40 → BILLING_RECOVERY
• CASE-2103: MOBILE_DATA abroad, line.roaming_enabled=true, device.phone_roaming_enabled=false → TOGGLE_ROAMING → SELF_SERVICE
• CASE-2104: MMS, device.can_send_mms=false, mmsc_url_present=true, storage=false → GRANT_MESSAGING_PERMISSION, permission="storage" → SELF_SERVICE
• CASE-2105: SLOW_DATA, vpn_connected=true → DISCONNECT_VPN → SELF_SERVICE
• CASE-2501: data_used_gb=16.2 ≥ plan.data_limit_gb=15.0, customer_preferences.accepted_refuel_gb=2.0, plan=PLAN-PREMIUM data_refueling_price_per_gb=2.0 → REFUEL_DATA, refuel_gb=2.0, charge=$4.00 → DATA_RECOVERY
• CASE-2502: abroad, line.roaming_enabled=false, device.phone_roaming_enabled=true → ENABLE_LINE_ROAMING, carrier_update_required=true → CARRIER_UPDATE
• CASE-2503: data_saver_mode=true → TOGGLE_DATA_SAVER → DEVICE_SETTING_FIX
• CASE-2504: network_mode_preference="3g_only" → SET_NETWORK_MODE → DEVICE_SETTING_FIX
• CASE-2505: mobile_data_enabled=false → TOGGLE_MOBILE_DATA → DEVICE_SETTING_FIX

3.2 Final-route conventions by flavor

carrier_update_required=true whenever primary_action=ENABLE_LINE_ROAMING (and only then) in Flavor-2.

3.3 Charge calculation

charge_amount_usd for billing / refuel cases:

• Billing-recovery (payment request): charge_amount_usd = overdue_bill.amount_due_usd (two decimals).
• Data refuel: charge_amount_usd = accepted_refuel_gb × plan.data_refueling_price_per_gb (two decimals).
• All non-billing actions: charge_amount_usd = 0.00.

3.4 Summary rollups

Flavor-1 charge_amount_usd is "number with two decimals"; Flavor-2 too. Flavor-2 data_refuel_gb is "number with one decimal", 0.0 when N/A.

4. Family C — Enterprise export-complaint response package

For each enterprise complaint payload (client_complaint_email.txt + response_requirements.json):

4.1 Identify the incident

1. GET /api/enterprise/incidents → find by incident_id (often present in the complaint email, e.g., "INC-7301") OR by matching summary keyword against the complaint subject/body.
2. Pull enterprise_account_id, engineering_owner, account_owner, severity from the incident record (these become engineering_owner/account_owner/severity in the response package — they are authoritative, do not derive from the email).

4.2 Identify failed export window and backfill

GET /api/enterprise/export-runs?incident_id=<incident_id>. Filter to runs where status == "FAILED". Sort by run_date ascending.

• failure_window.start_date = first failed run_date.
• failure_window.end_date = last failed run_date.
• failure_window.failed_days = count of failed runs.
• backfill_days = failed_days (manual backfill equals the number of failed runs).
• root_cause_category = human-readable summary derived from the failed runs' common failure_code plus message-board evidence (see below). E.g., STALE_CREDENTIAL ("scheduler still references old secret" message) → "stale credential after rotation". STAGING_STORAGE_QUOTA ("staging bucket reached quota") → "staging bucket quota".

4.3 SLA credit

GET /api/enterprise/sla/<enterprise_account_id>:

• sla_credit_percent = sla_contract.monthly_export_credit_percent (integer percent).
• The credit_trigger text is supporting evidence (e.g., "3 consecutive failed export runs" vs "critical export outage longer than 72 hours") — verify the failure condition is satisfied before asserting the credit in the package; the credit_percent value itself is taken verbatim.

4.4 Contributing alert issue

GET /api/enterprise/messages?query=<client keyword or incident id> and inspect the channels.

• If the early-alert message has channel containing "archive" (e.g., export-alerts-archive) → contributing_alert_issue = "ARCHIVED_ALERT_ROUTE".
• If no such archive-route evidence → "NONE" or "UNKNOWN" per template enum.

4.5 Owners and channel/evidence/report naming

GET /api/enterprise/accounts → find by enterprise_account_id:

• account_owner = the enterprise account's account_owner (authoritative, matches incident).
• engineering_owner = the incident's engineering_owner (authoritative).
• finance_owner = the enterprise account's finance_owner (used for share permission view tier).

Naming conventions (per response_requirements.naming_style):

• channel_name: client name → lowercase, hyphenated, punctation stripped. E.g., "Asteri Retail Inc." → asteri-retail-inc.
• evidence_folder: "<Client Name> <Month Year> Investigation". Use month/year of the failure window start. E.g., failure start 2026-05-12 → "Asteri Retail Inc. May 2026 Investigation".
• report_title: "<Client Name> Export Failure - Resolution Report".

response_status:

• sla_credit_percent > 0 → "NEEDS_FINANCE_REVIEW".
• (Coverage for other statuses in the enum READY_TO_SEND / NEEDS_ENGINEERING_REVIEW / UNDER_INVESTIGATION should drive off the SLA-credit result and incident.status.) Observed: closed SLA-credit case → NEEDS_FINANCE_REVIEW.

4.6 Share permissions

Take response_requirements.permission_users_to_include in order. For each user:

• If user matches enterprise_account.finance_owner → "view".
• The next listed user (typically engineering/owner role) → "edit".
• Any further users not on the finance tier → "upload_only" (enum value; inferred for the third-tier case).

Order the output array exactly as listed in permission_users_to_include.

Evidence (train_003): permission_users_to_include=["laura.brown","jun.chen"] → [{user:laura.brown,permission:view}, {user:jun.chen,permission:edit}]. laura.brown is ENT-3001.finance_owner → view tier.

4.7 Response-package field reference

5. Audit-math definitions (when test prompts request these)

These are computed over the batch of tickets the test prompt includes. Always compute over the tickets whose diagnostic_needed flag became true for diagnostic audits, and over ESCALATED/RESOLVED-with-troubleshooting tickets for post audits.

bandwidth_floor(tkt) = 0.80 × tkt.subscribed_mbps latency_floor = 100 (ms) jitter_floor = 30 (ms)

1. pre_troubleshooting_bandwidth_gap_total_mbps: Sum over every diagnostics-used ticket (those with diagnostic_needed == true) whose diagnostics.bandwidth_mbps < bandwidth_floor of (bandwidth_floor - bandwidth_mbps). Units: Mbps. Gated-out tickets are excluded (even if their API diagnostic record exists).

2. diagnostic_records_skipped_by_gate: Count of tickets where diagnostic_needed == false BUT the API actually returns a non-empty diagnostics record at /api/diagnostics/<ticket_id>. (These records were available but skipped because the gate decided the ticket.)

3. post_troubleshooting_remaining_issue_flags: For each "unresolved diagnostic ticket" (diagnostic_needed=true AND final_resolution_status==ESCALATED) count how many of {post_latency_issue, post_stability_issue, post_bandwidth_issue} are still true against the floors. Sum across all unresolved diagnostic tickets.

4. post_threshold_excess_totals: For each unresolved diagnostic ticket, compute:

   • latency_excess = max(0, troubleshooting.post_latency_ms - 100)
   • jitter_excess = max(0, troubleshooting.post_jitter_ms - 30)
   • bandwidth_short = max(0, bandwidth_floor(tkt) - troubleshooting.post_bandwidth_mbps) Sum (latency_excess + jitter_excess + bandwidth_short) across all unresolved diagnostic tickets. Report as a single total (ms + ms + Mbps aggregated).

5. tickets_using_post_troubleshooting_records: Count of tickets with diagnostic_needed == true AND a non-empty /api/troubleshooting/<ticket_id> record (i.e., post_ metrics were used to decide RESOLVED vs ESCALATED).

6. tickets_with_active_outage_match: Count of tickets for which an active outage (active=true, service_type in outage.service_types) sits in the ticket's service_area.

7. unique_escalation_teams: Sorted ascending set of distinct escalation_team values across the batch (excluding NONE).

8. root_cause_escalation_ticket_ids (by team): Map: team_name → sorted list of ticket_ids whose final escalation_team == team_name (i.e., the ESCOLATED tickets, grouped by their resolved escalation team per §2.4). Only populate teams that have at least one ticket.

9. post_success and post_failure id lists:

   • post_success_ids = sorted ascending list of ticket_ids whose final_resolution_status == RESOLVED (after troubleshooting, all post flags cleared).
   • post_failure_ids = sorted ascending list of ticket_ids whose final_resolution_status == ESCALATED (post still has at least one issue). Both limited to tickets that went through diagnostics (had a troubleshooting recheck).

10. Per-ticket floor + shortfall list (sorted by ticket_id ascending): For each diagnostics-used ticket, report:

    • ticket_id
    • bandwidth_floor_mbps = 0.80 × subscribed_mbps
    • bandwidth_shortfall_mbps = max(0, bandwidth_floor_mbps - diagnostics.bandwidth_mbps)
    • latency_floor_ms = 100
    • latency_excess_ms = max(0, diagnostics.latency_ms - 100)
    • jitter_floor_ms = 30
    • jitter_excess_ms = max(0, diagnostics.jitter_ms - 30) Sorted ascending by ticket_id.

6. Pitfalls and edge cases

• API URLs in prompts lie: any prompt printing http://127.0.0.1:8057 (or similar) must be ignored; the base URL is <remote-env-url>. Apply to every endpoint substitution.
• Gated-out tickets may still have diagnostics / troubleshooting records: those are "skipped by gate" for the audit. Do NOT compute pre issue-flags for them in the per-ticket answer; their flags go to false in Flavor-1.
• Bandwidth ratio only weakly constrained: train data narrows it to 0.697 < ratio ≤ 0.907 from TCK-5107 alone. Commit to 0.80 unless a test item contradicts (then revise proportionally). The jitter floor (≤21 to <33.5) and latency floor (≤82 to <97 from TCK-5402 pre being just below) commit to 30 ms and 100 ms.
• Outage service_type overlap: an outage applies only if the ticket's service_type is in outage.service_types. A plain active == true in the right service_area does not suffice — service_type must match.
• Order preservation: preserve the CSV payload order in ticket_decisions; preserve ascending case_id order in case_decisions.
• Permission users order: in Flavor-C, output share_permissions in the exact order of response_requirements.permission_users_to_include (do NOT sort alphabetically).
• route_team for OVERDUE_SUSPENSION is ACCOUNTS_PAYABLE even though the ticket is FAILED: the per-team summary counts include this ticket. Same for FRAUD_SUSPENSION if the test sets its team accordingly.
• Two mobile output flavors: same underlying decision tree, but Flavor-2 collapses billing/billing-recovery routes to DATA_RECOVERY and merges self-service fixes into DEVICE_SETTING_FIX. Watch the answer template before deciding which fields to emit.
• REFUEL_DATA needs both: line.data_used_gb ≥ plan.data_limit_gb AND explicit customer_preferences.accepted_refuel_gb in the worklist payload. If the customer refuses, fall through to other matches (often TRANSFER_HUMAN).
• root_cause → team matching: case-insensitive substring match. A single root_cause may contain multiple keywords (BACKBONE_CAPACITY matches both backbone and capacity → NETWORK_ENGINEERING).
• failure_window count vs duration: failed_days is the count of FAILED export runs, NOT the calendar span (e.g., 2026-05-12 to 2026-05-14 = 3 dates = 3 FAILED runs).
• SLA credit value comes verbatim from the SLA contract: never recompute from the number of failed days. Validate the trigger text is satisfied, but use the contract's monthly_export_credit_percent literally.
• response_status: when SLA credit > 0, status is NEEDS_FINANCE_REVIEW (finance_owner gets view permission in the share list); engineering gets edit. Verify against incident.status and sla.credit_trigger if the prompt insists on a different status enum.

7. Quick threshold summary (commit these numbers)

• Latency floor: 100 ms (inferred — TCK-5107 post=82 cleared, TCK-5407 post=121 still failing).
• Jitter floor: 30 ms (inferred — TCK-5107 post=21 cleared, all ESCALATED posts ≥32).
• Bandwidth ratio: 0.80 of subscribed_mbps (inferred — TCK-5107 pre=209/300 fails, post=272/300 passes; ratio window is 0.697–0.907).