Accounts Cockpit
Fuel loyalty card system · reporting
The operating rule this request is built on
Three sentences. Everything below follows from them.
- 1The ERP is the system of record. Every list this cockpit produces must be worked inside the ERP, not on a dashboard.
- 2The ERP vendor should not be asked to build charts. They should be asked to store the action, the owner and the timestamp — the reporting layer does the rest.
- 3One new table carries all of it. Nothing existing is renamed or retyped.
Every list this report produces, and where it is actually worked
A list with no place to be worked is a list nobody owns.
| List | Produced by | Worked in | Owner | Frequency |
|---|---|---|---|---|
| Declining / at-risk accounts | Business Overview | ERP call task | CS Pro Call | Weekly |
| Lapsed 30/60/90 days | Business Overview | ERP call task | CS Pro Call | Weekly |
| AR SOP stage queue | AR & Aging | ERP AR module | AR officer | Daily |
| Final Notice cohort | AR & Aging | ERP AR module | AR manager | Monthly |
| Rejected collections needing a call | Collections | ERP call task | AR officer | Daily |
| Open application queue | CS Card Admin | AOS + ERP | CS admin | Daily |
| Holiday follow-up list | Business Overview | ERP call task | Sales rep | Ad hoc |
Change requests for the ERP vendor
Seven items. Six are Must; none of them is a chart.
| ID | Change | Detail | Size | Priority |
|---|---|---|---|---|
| CR-01 | Create CALL_TASK table | One row per task assigned to a person, with source list, state and timestamps. | M | Must |
| CR-02 | Task creation API | Accept a batch of tasks from the reporting layer; idempotent on (account_no, source_list, period). | M | Must |
| CR-03 | CS task screen | Officer sees only their open tasks, can log outcome and close. | L | Must |
| CR-04 | Outcome code list | Fixed picklist, maintainable by the AR manager, no free text for the outcome itself. | S | Must |
| CR-05 | Reassign and escalate | Supervisor can reassign; auto-escalate on SLA breach. | M | Should |
| CR-06 | Task export / read API | Read endpoint so the cockpit can report compliance without screen-scraping. | S | Must |
| CR-07 | Audit trail | Every state change stored with user and timestamp, never overwritten. | S | Must |
One new table does all of it — CALL_TASK
CALL_TASK — column specification
Additive only. Nothing existing changes.
| Column | Type | Notes |
|---|---|---|
| task_id | bigint identity | Primary key. |
| account_no | varchar(20) | FK to customer account. |
| source_list | varchar(40) | Which list produced it, e.g. AT_RISK_30D. |
| period | varchar(10) | Period the list was produced for, e.g. 2026-08. |
| assigned_to | varchar(30) | ERP user id of the owner. |
| due_date | date | Set by the SOP for that list. |
| state | varchar(15) | OPEN / IN_PROGRESS / DONE / VOID. |
| outcome_code | varchar(20) | From the fixed picklist; null until DONE. |
| remark | varchar(500) | Free text, never used for reporting. |
| created_at | timestamp | Set on insert. |
| closed_at | timestamp | Set once, when state becomes DONE. |
| closed_by | varchar(30) | ERP user who closed it. |
Rules the ERP must enforce
These belong in the database, not in a screen validation.
- Unique on (account_no, source_list, period) — the same account cannot be raised twice for the same list and month.
- outcome_code is mandatory when state = DONE.
- closed_at and closed_by are written by the ERP, never accepted from the caller.
- A task can only be closed by its owner or a supervisor.
- VOID requires a reason and is reported separately from DONE.
- No hard delete — history is retained for audit.
Who builds what
The ERP vendor stores the action. Corsiva Lab does the reporting.
| Item | ERP vendor | Corsiva Lab | Note |
|---|---|---|---|
| CALL_TASK table and constraints | Yes | No | Schema and enforcement live in the ERP. |
| Task creation / read APIs | Yes | No | Vendor owns the contract. |
| CS task screen inside the ERP | Yes | No | Officers work where they already work. |
| List generation logic | No | Yes | Reporting layer decides who lands on which list. |
| Compliance and SOP reporting | No | Yes | Built from the task read API. |
| Dashboards and charts | No | Yes | The vendor is not asked to build charts. |
Phasing — CS switches once, never runs two systems
Each phase ends with a group of users fully moved across.
| Phase | Scope | Timing | Who switches |
|---|---|---|---|
| Phase 1 | Table, APIs, one list (AR SOP queue) end to end. | Weeks 1–4 | AR officers only. |
| Phase 2 | CS task screen, outcome picklist, reassign and escalate. | Weeks 5–8 | CS Pro Call moves across in one cut. |
| Phase 3 | Remaining lists, compliance reporting, audit exports. | Weeks 9–12 | Spreadsheet trackers retired. |
Acceptance criteria — how we sign off
Each line is testable by a person, not by reading code.
- 1A list produced by the cockpit appears as ERP tasks within 15 minutes, with no duplicates.
- 2An officer can see, work and close only their own tasks; a supervisor can reassign.
- 3Every closed task has an outcome code, a closer and a timestamp the officer cannot edit.
- 4SOP compliance for a chosen month can be reported entirely from the read API.
- 5Re-running the same list for the same month creates no new rows.
- 6CS runs one system — no parallel spreadsheet is needed to know what is outstanding.