Operations Coordinator
Triage, schedule, assign and coordinate
Back to Work
03 / Custom Web Applications
Custom Operations System
One controlled workflow from service request to operational closure.
Designed around an illustrative commercial maintenance operation, this working product connects triage, dispatch, Technician execution, exceptions, Client decisions and Finance handoff while preserving authority, ownership and audit history.
Concept-to-implementation case study
No real Client engagement or measured production outcome is claimed.
01 / Operating model
The business process comes before the dashboard.
The scenario begins with a common coordination problem: requests, schedules, field updates, evidence, approvals and handoffs distributed across separate tools. It is illustrative, not a claim about a real Client's operation.
A generic project tracker could store tasks, but it would not necessarily preserve the difference between incoming demand and accepted work, freeze the relevant service commitment, enforce assignment-level field access or model who owns an exception decision.
Custom software earns its place here by making those operational distinctions executable. The design objective is traceable ownership and controlled handoffs—not a prettier collection of cards.
Illustrative fragmented process
- 01Phone, email and messages
- 02Manual interpretation
- 03Spreadsheet and calendar
- 04Technician coordination
- 05Chat-based evidence
- 06Approval threads
- 07Separate Client and Finance follow-up
Implemented controlled workflow
- 01Service Request
- 02Controlled triage and conversion
- 03Work Order
- 04Schedule and Assignment
- 05Technician execution and Evidence
- 06Exception and explicit approval
- 07Client sign-off, Finance handoff and closure
02 / Workflow boundaries
State, schedule and ownership are separate decisions.
The server governs lifecycle transitions. Scheduling records when work should happen; Assignment identifies the exact Technician who currently owns field execution.
Primary lifecycle
- 01Ready to schedule
- 02Scheduled
- 03Assigned
- 04Accepted
- 05In progress
- 06Completed
- 07Client sign-off
- 08Finance handoff
- 09Closed
03 / Decisions and authority
Exceptions become owned decisions, not comments in a thread.
Reporting an exception blocks work, creates a numbered approval attempt and identifies the decision owner. Approval and resumption remain separate commands so the audit history reflects what actually happened.
Role-specific interfaces
Operations / Technician / Client / Finance
Server command and policy boundary
Revalidate state / authorize scope / actor-bound idempotency / serializable transaction / activity event
Authoritative operational model
Next.js 16.3.3 / Prisma 7.10.0 / PostgreSQL 18
04 / Evidence and scope
Completion stays distinct from Client acceptance and Finance.
Technician completion prepares a Client-safe sign-off package. Accepted sign-off creates a ready Finance handoff; Finance acknowledgement then closes the operational lifecycle without pretending to invoice or collect payment.
Unit and integration
140 Vitest tests passed across 21 files.
Production browser
60 unique Playwright tests passed across desktop and mobile projects.
Accessibility checks
Representative axe, keyboard, focus, reduced-motion and 200% reflow checks passed.
Code quality
Lint, strict TypeScript and the production build passed.
Data layer
PostgreSQL 18.6 was healthy; Prisma validated and generated, all nine migrations were current, and repeatable seed verification passed.
Decisions and trade-offs
Service demand is not executable work
A Service Request can be incomplete, duplicated, cancelled or closed without work. Only controlled conversion creates a Work Order and freezes the applicable service context.
Trade-off: The extra record boundary adds triage steps, but prevents every message from becoming an operational commitment.
Approval does not silently resume the job
An exception blocks execution and creates a numbered, immutable approval attempt. A later decision records authority; a separate command deliberately resumes work.
Trade-off: The additional action avoids hidden state changes, but requires Operations to make resumed ownership explicit.
Finance receives a handoff, not fictional accounting
Accepted Client sign-off prepares verified service context for Finance. Finance acknowledgement closes the operational lifecycle without creating an invoice or payment claim.
Trade-off: The portfolio proves a clean boundary and stops before accounting, rather than simulating a larger product surface.
Implemented and verified
Service operations from demand intake through operational closure, including server-authoritative transitions, scoped interfaces and audit events.
Deliberately deferred
Invoicing, payment, GPS, routing, inventory, production object storage and malware controls, offline-native synchronization, workflow builders, AI and predictive analytics.
What this project demonstrates
Translating business-process analysis into distinct domain records, explicit state transitions, role-and-resource authority, responsive interfaces, transactional commands, private evidence, controlled decisions and a tested operational loop. The Command Centre surfaces attention from those records; it is not a claim of analytics, utilisation, prediction or measured performance.
Related service
Have a related business problem?
This record is transparent about its current evidence. Your project can begin with the problem you are trying to solve.