Fewshot Attempt 03

CRM Support Console — Reusable Skill

Base URL

Use the URL from environment_access.md. Ignore 127.0.0.1 / localhost in task prompts. Known public base: http://34.46.77.124:8003 (verify against environment_access.md).

Core API Reference

Ticket Triage Rules (Internet / Video / Voice)

Step 1 — Account Lookup

• Call GET /api/accounts/<account_id>.
• If the account does not exist or the account_id is malformed (e.g., BAD-*): FAILED / INVALID_ACCOUNT.
• If the account is suspended / on hold / overdue: FAILED / INELIGIBLE_ACCOUNT (or OVERDUE_SUSPENSION with route ACCOUNTS_PAYABLE in SLA-review contexts).

Step 2 — Outage Check

• Extract the service_area from the account.
• Call GET /api/outages?service_area=<area>.
• If an active outage matches the ticket's service_type (internet / video / voice): PENDING_ACTION / OUTAGE_WAIT (route: ACTIVE_OUTAGE). No diagnostic needed. Include the outage_id.

Step 3 — Diagnostics & Resolution

• If account is valid and no outage: call GET /api/diagnostics/<ticket_id>.
• Map diagnostic flags directly to the boolean issue fields (latency_issue, stability_issue, bandwidth_issue).

Resolution routing by symptom/root-cause:

Diagnostic Flag Convention

• diagnostic_needed: true → RESOLVED and ESCALATED technical tickets.
• diagnostic_needed: false → FAILED tickets, outage-wait tickets.
• When diagnostics run, ALL flags reflect what the API returns (do not zero them out just because one is false).

Mobile Case Queue Rules

Step 1 — Case Lookup

• GET /api/cases/<case_id> → extract customer_id, line_id.
• GET /api/lines/<line_id> → line status, roaming, network_mode, data_saver, vpn, mobile_data, permissions.

Step 2 — Issue → Action Mapping

Permission Field

• NONE unless the action is GRANT_MESSAGING_PERMISSION → then use storage.
• In some task variants, sms or sms_and_storage may appear; check line permissions API.

Bill / Charge Rules

• bill_id: empty string "" unless a bill payment is involved (SEND_PAYMENT_REQUEST).
• charge_amount_usd: always a number with two decimals. For billing cases, use the actual bill amount from the API. For data refuel: refuel_gb × 2.00.
• Data refuel pricing: $2.00 per GB.

Enterprise Incident Response Rules

Step 1 — Incident Lookup

• GET /api/enterprise/incidents/<incident_id> → enterprise_account_id, severity, engineering_owner, account_owner.

Step 2 — Export Runs

• GET /api/enterprise/export-runs?incident_id=<id> → find the contiguous failed window.
• start_date = first failed day, end_date = last failed day.
• failed_days = count of consecutive failures in the window.
• backfill_days = same as failed_days (manual backfill covers every failed day).

Step 3 — Root Cause

• GET /api/enterprise/messages?query=<keywords> with terms from the complaint (e.g., "export", "credential", "rotation", "pipeline").
• Derive a concise root-cause string (e.g., "stale credential after rotation").
• Check for alert mentions. If alerts were archived before the failure: contributing_alert_issue = "ARCHIVED_ALERT_ROUTE". Otherwise NONE or UNKNOWN.

Step 4 — SLA

• GET /api/enterprise/sla/<enterprise_account_id> → credit percentage for the failure duration/severity.

Naming Conventions

• channel_name: Client name lowercase, hyphenated. E.g., "Asteri Retail Inc." → "asteri-retail-inc".
• evidence_folder: "<Client Name> <Month> <Year> Investigation". E.g., "Asteri Retail Inc. May 2026 Investigation".
• report_title: "<Client Name> Export Failure - Resolution Report".

Share Permissions

• Always a list of {user, permission} objects.
• Order: match the order in permission_users_to_include from requirements.
• Permission values: view, edit, or upload_only.

Severity Triage

• Multi-day export failure blocking executive reporting → Critical.
• Use the severity from the incident API if available; otherwise infer from impact.

Response Status

• If SLA credit > 0% → NEEDS_FINANCE_REVIEW.
• If root cause uncertain → UNDER_INVESTIGATION or NEEDS_ENGINEERING_REVIEW.
• Fully resolved with no credit → READY_TO_SEND.

SLA Queue Review Rules (Train 004 variant)

Same triage as ticket rules above, with these additional key_blocker mappings:

Output Conventions (Checklist)

1. Preserve input order — tickets/cases in output must match the order in the input payload.
2. All enum values — copy exactly from the answer template. No invented values.
3. Empty strings vs null — use "" for absent IDs (outage_id, bill_id). Never null.
4. Numeric types:
   • charge_amount_usd: always two decimals (0.00, 86.40, 4.00).
   • data_refuel_gb: one decimal (2.0, 0.0).
   • Counts / percentages: plain integers.
5. Booleans — lowercase true / false.
6. Summary counts must sum correctly — verify each summary field against the decision list before returning.
7. Date format — YYYY-MM-DD strings.
8. Never fabricate data — always pull from API responses. If an API field is absent, default to the zero-value for its type.

Common Pitfalls

• Forgetting to override localhost — always use the environment_access.md base URL, never 127.0.0.1.
• Calling diagnostics for outage tickets — skip diagnostics when an active outage is found; the ticket is PENDING_ACTION.
• Calling diagnostics for FAILED tickets — skip for INVALID_ACCOUNT, INELIGIBLE_ACCOUNT, AUTH_FAILED.
• Missing the outage check — always check outages BEFORE diagnostics; an outage changes the entire resolution path.
• Wrong escalation team — FIELD_OPS for physical/field issues, NETWORK_ENGINEERING for capacity/backbone, TIER2_SUPPORT for provisioning/config.
• Forgetting customer_preferences — when the payload includes customer_preferences, check the case_id key for accepted_refuel_gb and does_not_want_plan_change.
• Mixing up TOGGLE_ROAMING vs ENABLE_LINE_ROAMING — TOGGLE_ROAMING is a device-side action (phone setting), ENABLE_LINE_ROAMING is a carrier-side provisioning change (carrier_update_required: true).
• Missing secondary_action — always include it even when NO_ACTION; never omit the field.
• Summary miscounts — double-check that batch_summary / queue_summary / worklist_summary counts exactly match the decisions array.

Compact SOP

1. Read the answer template first — it defines the output shape and enums.
2. Read all input payloads (CSV, JSON, email).
3. For each ticket/case in order: a. Fetch the entity from the API (ticket, case, incident). b. Fetch related records (account, line, plan, device, outage, SLA). c. Apply the triage rules above to determine status, route, blockers, and flags. d. Populate one entry in the decisions array.
4. Compute summaries by counting across the decisions array.
5. Validate enum values, numeric formats, and summary counts.
6. Return only the JSON object matching the answer template — no markdown, no explanation.