A structured walkthrough of the scoping phase: how we mapped the four platforms, what we found across their capabilities, and where the processes break down.
The starting point: understanding each platform on its own terms before looking at how they connect. We walked through all four systems with their respective teams, documented what each one did, who used it, and how it was technically structured.
Judges, magistrates, tribunal officers. Make decisions on cases, conduct hearings, approve orders. Many work across multiple systems.
Operational backbone. Process filings, schedule hearings, manage case records, coordinate with agencies. Heaviest system users.
File cases, manage documents, track hearings, pay fees via external portals. Subscription access on System A, per-case access elsewhere.
Members of the public filing and managing cases without legal representation. Primary users of System D, but also appear in Systems B and C.
Police, prosecutors, social services, hospitals, MSF. Interact via agency portals, mostly on Systems B and C. 30+ agency interfaces documented.
Mediators, counselors, interpreters, bailiffs. Specialist roles that appear across systems with different access levels and capabilities.
A cross-system view of twelve capability categories assessed during the scoping phase. Each cell reflects what the system actually did in day-to-day operation — not what it was designed to do.
File sizes reach 100s MB. 100s TB total storage. No in-app multimedia preview. High storage cost from absence of archival.
Low file size limit forces document splitting on complex cases (up to 1,000 charges). Some OCR capability. TCQ micro-frontend for doc rendering.
Low file size limit. No in-app preview — planned multimedia preview platform. PDF-only, limiting complex cases.
Simple cases; 5MB file limit is sufficient. PDF preview via browser. OCR initiative in progress.
Not standardised, not centrally managed. Changes require vendor intervention. Differences across court divisions.
Separately implemented. Most cited pain point across all sessions. No central repository.
Disparate from other systems. Family-specific templates not aligned with civil equivalents.
Separate implementation. Tribunal orders and notices not aligned with any other system.
Intake forms need simplification. Minute sheets tailored per court division. Changes difficult when in code.
Separate implementations. Minute sheets highly specialised. Cross-court alignment needed.
Complex multi-party forms (MCA, maintenance). Not aligned with civil or criminal patterns.
Simpler forms but SRPs find them confusing. No built-in guidance or smart validation.
Search barely used — doesn’t work well. No cross-system index. Keyword only.
Users report search largely meets requirements. No cross-system capability.
Search meets requirements within system. No integration with other case records.
Basic search for own cases only. No global search needed at current volume.
No courtroom document synchronisation.
Only platform with broadcast — judge navigates, all parties follow. Occasional instability.
No broadcast functionality.
Judges review uploaded documents independently.
No archival. 100s TB on fast-access storage. Glacier dropped due to access delay.
Access to SCRIMS archived cases. No archival for current cases.
No archival. Long retention needed for ongoing family proceedings.
Considering Glacier after 10 years. DB still manageable. Not urgent.
Separately implemented. Shared data manually entered. Insufficient cross-system sync.
400+ cases/day amplifies cost of manual reconciliation. Background processes for conflicts.
Room booking intersects with other court calendars. No shared view.
DayPilot JS calendar. Simpler scheduling needs. Adequate for current volume.
Coverage uneven. Users across courts experience significant variation in task management.
Case queue, task list, calendar. Most complete workflow implementation of the four.
Workflow and task assignment present. Supports multi-party proceedings.
Basic case folder and task list. Adequate for simple tribunal cases.
In-app inbox, email, SMS. Redundant SGTS gateways for internal vs external users.
Aligned approach overall. Multiple overlapping gateways at high volume.
Broadly functional. Some redundancy with civil system gateways.
Simpler needs. In-app and email. No SMS complexity.
Subscription model for law firms. Fee structure not aligned with other systems. Gateway reliability issues.
Bail and fine collection via IFAS. Two systems involved in every payment flow.
Ongoing maintenance payment tracking (recurring orders). Unique family law complexity.
Filing fees only. eNETS and PayNow. Simpler fee structure.
Many queries require manual DB access by vendor. Tableau on small subset. Lost key power user.
Reporting DB via AWS DMS. Qlik dashboards. Coverage inconsistent.
Elixir vendor reporting. Tableau used directly by statistics team (strongest in courts).
Monthly DB dump for stats. No self-service dashboard.
SingPass/CorpPass + WOG AD + CAM. Each court division has its own roles. No unified matrix.
Multi-level roles: JO, CO, RO, Bailiff, Interpreter, Call Centre, PPO, plus agencies.
Agency users use SingPass/CorpPass. Social workers, mediators, DJOs have separate roles. Most complex matrix.
SRPs and companies share portal. CJTS Pass for users without SingPass. Fine-grained tribunal roles.
Where the processes break down, what the cross-system patterns revealed, and what we flagged for the discovery phase to investigate.
These are the points where the current systems create friction that users have built workarounds for. Each represents a gap that the scoping phase surfaced for discovery to investigate further.
Cited in virtually every stakeholder session across all four systems. Templates for notices, orders, and letters are maintained separately, are difficult to change without vendor involvement, and are not standardised. Court officers described spending significant time reformatting documents that should have been templated.
File size limits that work for simple cases become severe constraints for complex ones (criminal cases with 1,000+ charges, each with files). No in-app multimedia preview means complex hearings require workarounds. No consistent archival approach across any platform.
Court officers, registry staff, and senior judicial officers routinely work across two or more systems. None of the platforms was designed for this user. User management is duplicated, role matrices are inconsistent, and there is no shared view of workload or case status.
Room availability, court holidays, hearing quotas — data used by all four platforms — has no system of record. Each system maintains its own copy, manually synchronised. This can’t be fixed by improving any single system.
With 400+ cases a day on System B alone, the cost of manually resolving scheduling conflicts across four independently-managed calendars is substantial. No cross-system scheduling view exists.
Four different vendor relationships with different responsiveness, code ownership, and documentation quality. The oldest vendor relationship had deteriorated significantly. Modernisation sequencing must account for vendor capacity and contract timelines.
Templates, forms, document management, search, archival, reporting, and user management all showed fragmentation or absence across multiple systems. Only notifications were broadly aligned.
No capability had been designed to work across all four platforms. Every one was implemented independently. Even where approaches were aligned (e.g. notifications), there was no shared infrastructure.
Only the Criminal platform had courtroom document synchronisation. The other three had no equivalent. This was raised as a priority by judicial officers across all courts.
The scoping phase was not asked to solve these problems. But it was asked to identify where the real complexity lived so that discovery would be looking in the right places.
| Area | Priority | What discovery needs to investigate |
|---|---|---|
| Template management | High | How templates are actually used day-to-day, what a centralised approach would need to support, which template types are shared across courts vs. court-specific. |
| Document management | High | The real cost of document-splitting workarounds, multimedia evidence handling during hearings, and whether a unified document service is feasible across four different storage architectures. |
| Cross-system user experience | High | How many users work across 2+ systems, what their daily workflows look like, and what a unified workload view would need to contain. This is likely a larger population than leadership expects. |
| Shared data ownership | High | Who should own room availability, court holidays, and hearing quotas. This is a programme-level governance question, not a technical one. Needs stakeholder alignment before any system changes. |
| Appeals cross-system flow | Medium | How frequently the System B → System A appeals path is used, what the handoff experience is like for lawyers and judges, and what breaks when case documents cross system boundaries. |
| Vendor constraints on sequencing | Medium | Contract timelines, code ownership arrangements, and vendor capacity across all four platforms. These are hard constraints that will shape what can be modernised first. |
| Shared deployment coupling (B + C) | Medium | Whether Systems B and C can be decoupled for independent modernisation, or whether their shared infrastructure means they must be treated as a single workstream. |
| Broadcast capability expansion | Lower | Whether the courtroom broadcast feature from System B can be generalised to other platforms, and whether it’s the right approach for different hearing types. |