Scope
Prepared for Example Shire Council · 13 October 2026
| In scope | Not in scope |
|---|---|
| The decision logic for resident issues, from the proof, hardened and versioned | Changes to the customer request system beyond the queues it needs |
| The data record: loading, checks and definitions | Records not named in this scope |
| The workflow into the operations meeting agenda | Ongoing support, which has its own agreement |
| Handover: runbook, training, two supported weeks | New decisions. Each is scoped on its own |
Some platforms can now leave your data in your warehouse, which is good. The question is where your identity rules, segments and agents live.
| Task | Who | When |
|---|---|---|
| Review the Friday list | Coordinator, Customer Service | Weekly, Friday 10:00 |
| Approve a rule change | Manager, Community Services | As needed |
| Check the source records loaded | Customer service officer | Daily, 09:00 |
| Annual rule review | Manager, Community Services | Each July, with the budget cycle |
Running costs for cloud and models continue after handover. This scope lists each one for the Council’s budget.
| Milestone | Accepted when | Week |
|---|---|---|
| Records loading daily | Two weeks of loads pass the checks | 3 |
| Logic live alongside the current process | The owner signs off a week of comparisons | 6 |
| Workflow live | The Friday list runs without NTWRK for one week | 9 |
| Handover | Runbook signed off; two supported weeks done | 11 |
Support sits under a separate agreement with a defined purpose. The system stays documented so the Council could appoint another provider.
Either side can propose a change in writing. Each change states what it adds, what it removes and what it does to the milestones.
Set in the accompanying proposal, as a fixed fee for this scope. [Proposal reference]