Phase 01
Business problem and project framing
Frame the service problem before proposing technology. The baseline identifies measurable symptoms while discovery tests the causes.
Inspect the evidence
Problem register
| ID | Observed problem | Synthetic signal | Candidate response |
|---|---|---|---|
| PP-01 | Incomplete intake | 58.0% first-pass complete | Guided fields and dynamic checklist |
| PP-02 | Duplicate entry | 9.6 manual touches | Create the case once |
| PP-03 | Manual queue decisions | 29.8% SLA attainment | Explainable routing rules |
| PP-04 | Weak status visibility | 1.24 inquiries per application | Safe status and next action |
| PP-05 | Inconsistent closure | 9.2% reopen rate | Single decision event |
| PP-06 | Late management insight | 394 year-end backlog | Governed event and KPI model |
In scope
- Intake across digital and assisted channels
- Document validation and case creation
- Routing, status events and management reporting
- Controlled pilot and measurement design
Out of scope
- Municipal policy redesign
- Production procurement or vendor selection
- Real resident or employee data
- Automated final eligibility decisions
My analysis and method Why this phase matters
A business case aligns the problem, boundaries, evidence and decision. It prevents the project from becoming a solution looking for a problem.
Capability demonstrated
What this work shows
Translated an ambiguous service concern into a measurable problem statement.
Separated intake and service-flow improvement from policy redesign and procurement.
Used baseline measures as discovery signals, not causal proof.
Fictional municipal scenario, synthetic data, simulated discovery and validation. No City of Toronto affiliation or claimed production outcome.