# Task Group 004 Fewshot Attempt 02

> Use this skill whenever a task asks for ApexCloud CRM, ApexCloud Retention Operations API, renewal risk, retention action boards, QBR metrics packets, receivables and pipeline reviews, or churn export validation. It guides API collection, source precedence, controlled labels, ranking, precision, and JSON-only output for ApexCloud customer success and retention analytics.

- Skill: `prism-shadow/task-group-004-fewshot-attempt-02` (Agent Skill)
- Install (CLI): `npx skillmds@latest add prism-shadow/task-group-004-fewshot-attempt-02`
- Raw SKILL.md: https://api.skillmd.com/api/skills/prism-shadow/task-group-004-fewshot-attempt-02/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: DevOps & Infra
- Author: prism-shadow (https://skillmd.com/u/prism-shadow)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/prism-shadow/task-group-004-fewshot-attempt-02

---


# ApexCloud Retention Analytics

Use this skill to produce deterministic JSON analytics from the ApexCloud Retention Operations API. The recurring work is to reconcile account profiles, account metrics, support tickets, NPS, billing/ARR, A/R aging, opportunities, HR/event context, and churn CSV exports into the exact answer template supplied by the task.

## Operating Rules

1. Read the task prompt and `input/payloads/answer_template.json` before computing anything. The template is the contract: preserve all requested top-level keys, nested keys, enum vocabularies, nullability, and list shapes.
2. Use only the account IDs, candidates, regions, periods, dates, and endpoint families named by the active task. Do not expand the cohort unless the prompt asks for all accounts or all regions.
3. Return JSON only. Use numbers as numbers, not strings. Round only final values: currency to 2 decimals, percentages to 1 decimal, probabilities to 3 decimals, counts and ranks as integers.
4. Controlled labels must exactly match the template vocabulary. Do not invent synonyms such as `save_play`, `finance_followup`, or `tech_recovery`.
5. If prompt prose lists fewer top-level keys than the template, keep the template keys. In these tasks, `policy_codes` may appear in the template even when the prompt summary omits it.

## API Usage

Use the API base URL explicitly allowed by the current task or controlling instruction. In evaluation harnesses, a proxy base such as `http://127.0.0.1:8066` can supersede a historical port embedded in sample prompts.

Common public endpoints:

- `GET /api/accounts` for CRM account records and legal names.
- `GET /api/accounts/<account_id>` for profile fields such as `legal_name`, `region`, `segment`, `renewal_date`, `contract_tenure_months`, `lifecycle_status`, `crm_arr`, and account-level billing fallback fields.
- `GET /api/accounts/<account_id>/metrics?start=YYYY-MM&end=YYYY-MM` for monthly `recognized_revenue`, `product_usage`, active seats, and coarse metric snapshots.
- `GET /api/accounts/<account_id>/tickets?start=YYYY-MM-DD&end=YYYY-MM-DD` for support ticket truth, ticket hygiene, and SLA compliance.
- `GET /api/accounts/<account_id>/nps?start=YYYY-MM-DD&end=YYYY-MM-DD` for dated NPS responses.
- `GET /api/finance/ar-aging?as_of=YYYY-MM-DD` for A/R buckets.
- `GET /api/opportunities?start=YYYY-MM-DD&end=YYYY-MM-DD` for pipeline and expansion opportunities by close date.
- `GET /api/hr/summary?quarter=YYYY-QN` for regional HR operations context.
- `GET /api/events/performance?event=<event_id>&quarter=YYYY-QN` for event order and revenue context.
- `GET /exports/churn/train.csv`, `/exports/churn/validation.csv`, and `/exports/churn/candidates.csv` for churn modeling tasks.

If a prompt exposes a billing snapshot endpoint, use it as the authoritative source for current ARR. If not, account profile billing fields are a fallback and `crm_arr` is a last resort. Do not use `recognized_revenue` as ARR.

## Source Precedence And Hygiene

- Current ARR: prefer billing snapshot current ARR, then account billing ARR fallback, then CRM ARR only when no billing source exists. Policy code `REV-4` corresponds to using the billing ARR source.
- Revenue in QBR monthly packets: use `metrics[].recognized_revenue`, not ARR.
- Clean support tickets: exclude tickets where `is_duplicate` is true, `is_spam` is true, or `status` is `cancelled`. Include real open and closed tickets.
- Monthly support ticket counts: count clean tickets by `created_date` month. Do not rely on `metrics.support_ticket_count` when ticket-level data is available.
- SLA compliance: among clean tickets, a ticket is SLA-clean only when both `first_response_sla_met` and `resolution_sla_met` are true. Monthly SLA percent is SLA-clean tickets divided by clean tickets.
- NPS: use non-retracted NPS responses sorted by `response_date`. Latest NPS is the latest valid response. Monthly NPS comes from the valid response in that month when present; use `null` only if the template permits missing values.
- Product usage trend: compare the first and last months in the requested period, or use `UsageTrendPct` from churn exports when the task is explicitly export-based.
- A/R overdue balance for retention and receivables work: use older buckets `61_90 + 90_plus`. Do not include `current`, `1_30`, or `31_60` unless the prompt explicitly defines overdue differently.
- CRM matching for A/R customers: link only customers that are actual CRM accounts, normally by exact legal name. Do not fuzzy-link subsidiaries, foundations, country variants, or near-matches just because they resemble an account alias.

## Risk And Action Rules

Reason codes:

- `overdue_receivable`: older A/R bucket balance is greater than zero.
- `renewal_window`: renewal date falls inside the task's renewal window, usually within about 90 days after the assessment date or inside the requested period.
- `nps_drop`: latest valid NPS is poor or materially worse than earlier period sentiment.
- `sla_degradation`: any meaningful clean-ticket SLA miss, or low clean-ticket SLA compliance.
- `usage_decline`: product usage or active-seat trend declines over the requested months.
- `low_tenure_high_churn`: short-tenure and high-churn profile, especially month-to-month or low-tenure accounts in churn exports.
- `expansion_offset`: account has open expansion pipeline in the requested close-date window.
- `clean_billings`: no older overdue A/R balance; include only when the template's reason vocabulary includes it and it helps explain a lower-risk account.

When a `risk_score` is required, use a consistent 0-100 additive score, cap at 100, and make the drivers explainable through reason codes. Weight overdue receivables, renewal timing, poor NPS, SLA degradation, and usage decline most heavily; use low tenure and lifecycle context as secondary risk; treat expansion pipeline as an exposure offset, not a reason to ignore risk.

Risk levels should follow the score or overall severity consistently:

- `critical`: acute multi-factor risk, usually high exposure plus urgent renewal, sentiment/support, or receivables pressure.
- `high`: clear material risk with several drivers or one severe driver.
- `medium`: actionable risk but less urgent or lower exposure.
- `low`: monitor-only or hygiene/contextual risk.

Primary action priority:

- `collections_followup`: use when older overdue receivables exist.
- `technical_recovery`: use for SLA, support, usage, or product-health recovery when receivables do not dominate.
- `renewal_save`: use for renewal-window or low-tenure churn risk without collections priority.
- `executive_qbr`: use for high-value strategic accounts where executive alignment is the best next move.
- `nurture_monitor`: use for low-risk accounts that still need observation.
- `no_action`: use only when the template allows it and no follow-up is warranted.

For retention action boards, standard board order is severity descending, then revenue exposure descending within the same severity, with ranks assigned after sorting. For top-risk lists, sort by risk score descending. For churn candidate lists, sort by predicted churn probability descending.

## Receivables, Pipeline, HR, And Event Reviews

- Receivables follow-ups start from A/R customers with `61_90 + 90_plus > 0`. `overdue_balance` is that older-bucket sum.
- Sort `overdue_followups` by `customer_name` ascending when requested.
- `link_status` is `linked` only when the A/R customer maps to an actual CRM account. Use `account_id: null` for unlinked customers.
- Pipeline windows are based on opportunity `close_date`, not created date.
- `won_count` and `won_revenue` use closed-won opportunities in the window. `lost_count` uses closed-lost opportunities. `open_count` and `open_pipeline` use opportunities with `state: open`.
- `win_rate_pct = won_count / (won_count + lost_count) * 100`; if there are no closed won/lost opportunities, report 0.0 unless the prompt says otherwise.
- `top_open_product_line` is the product line with the largest summed open pipeline, not necessarily the highest count.
- HR all-region context sums regional `headcount` and `unpaid_claims_amount`.
- Event context uses the requested event and quarter fields directly, commonly `event_orders` and `event_revenue`.

## QBR Metrics Packets

For each requested month:

- `revenue`: monthly `recognized_revenue`.
- `support_tickets`: clean ticket count for that month.
- `sla_compliance_pct`: clean-ticket SLA percent for that month.
- `nps_score`: valid NPS response score for that month.

Highlights:

- `average_revenue`: average of monthly revenue values.
- `peak_revenue_month` and `peak_revenue`: max monthly revenue.
- `max_sla_month` and `max_sla_pct`: max monthly clean-ticket SLA percent; break ties by earliest month unless the prompt says otherwise.
- `peak_nps_month` and `peak_nps_score`: max valid monthly NPS; break ties by earliest month.
- `ticket_trend`: `improving` if clean tickets decline from first to last month, `worsening` if they rise, else `flat`.

Metric source enums commonly map to:

- revenue: `crm_closed_won` for recognized-revenue CRM metrics unless the prompt asks for billing.
- support_tickets: `support_export`.
- sla_compliance: `sla_report`.
- nps: `nps_survey`.

## Churn Export Validation

For churn CSV tasks:

1. Load train, validation, and candidate CSVs from the public export endpoints.
2. `training_rows` and `validation_rows` are data row counts.
3. `feature_count` excludes `customer_id` and the target column such as `Churn`.
4. Train a deterministic logistic classifier or equivalent reproducible binary model from train.csv. One-hot encode categorical columns; keep numeric columns numeric; apply the same preprocessing to validation and candidates.
5. `accuracy_pct` is validation classification accuracy times 100, rounded to 1 decimal. Use a 0.5 probability threshold unless the task says otherwise.
6. `tenure_coefficient_direction` is the sign of the trained tenure feature coefficient: `negative`, `positive`, or `zero`.
7. Candidate `predicted_churn_probability` is a 0-1 probability rounded to 3 decimals, not a percent.
8. Rank only the requested candidate IDs, even if the candidate export contains more rows.

Outreach mapping for churn candidates should be driven by the most salient driver: overdue receivable -> `collections_followup`; low tenure or renewal timing -> `renewal_save`; SLA/usage/support health -> `technical_recovery`; clean billing and very low probability -> `nurture_monitor`.

## Common Field Meanings

- `current_arr`: current annual recurring revenue from billing-preferred ARR source.
- `latest_nps`: latest non-retracted NPS response in the analysis period.
- `clean_ticket_count`: number of non-duplicate, non-spam, non-cancelled tickets in the analysis period.
- `overdue_balance`: older A/R balance, normally `61_90 + 90_plus`.
- `arr_at_risk`: sum current ARR for accounts classified as critical, high, or medium risk, or the task's explicitly defined at-risk cohort.
- `open_expansion_pipeline`: sum open expansion opportunity amounts in the requested window.
- `net_revenue_exposure`: `arr_at_risk - open_expansion_pipeline` when the template asks for an exposure formula.
- `collections_count`: count accounts or follow-ups whose primary action is `collections_followup`, depending on the surrounding object.
- `technical_recovery_count`: count accounts whose primary action is `technical_recovery`.

## Policy Code Conventions

When the template offers these policy-code enums and the prompt does not define different policies, use the standard ApexCloud choices:

- `risk_model_code`: `RS-6`
- `arr_source_code`: `REV-4`
- `support_hygiene_code`: `SUP-8`
- `action_priority_code`: `ACT-5`
- `board_sort_code`: `BORD-4`
- `exposure_formula_code`: `EXP-6`
- `calendar_policy_code`: `CAL-5`
- `receivable_trigger_code`: `RCP-7`
- `crm_match_code`: `CM-5`
- `pipeline_window_code`: `PW-6`
- `followup_scope_code`: `FS-4`
- `model_protocol_code`: `MOD-7`
- `probability_scale_code`: `PRB-4`
- `deployment_rule_code`: `DEP-5`
- `outreach_mapping_code`: `OUT-2`

## Final QA Checklist

- The output parses as one JSON object and contains no markdown.
- All lists have exactly the requested length and rank/order.
- All enum values match the template exactly.
- All calculations use the requested date/month/quarter windows.
- Ticket counts and SLA use clean ticket logic.
- A/R overdue balances use older buckets only.
- CRM matching avoids fuzzy-linking noise entities.
- ARR uses billing-preferred source, not CRM ARR or monthly revenue.
- Rounding is applied only at final output precision.

