Every activity has an owner,and a date it was due.
How a transformer manufacturer moved stage-wise dispatch planning off Excel and onto a workflow system - every activity assigned to a named person, executed against a planned date, reviewed, witnessed by the customer where required, and approved before it can be called complete.
The situation
Stage-wise plans lived in Excel. Each job carried its stages, each stage its activities, each activity a planned start and end date - and none of it was connected to whether the work had actually happened. Planned dates and actual dates sat in different places, so the gap between them only became visible when someone went looking, which was usually after it mattered.
What filled the gap was follow-up. Someone chased department heads to find out who was doing what. Someone chased the responsible person to find out whether it was done. Someone chased the reviewer. Ownership of a pending activity was rarely written down anywhere, so establishing it meant a phone call, and the answer lived in that call rather than in the plan.
The same fragmentation applied to the evidence. Comments sat in email, supporting attachments on individual machines, approvals in whoever’s inbox they had landed in. And because review, customer witnessing and approval each depended on someone noticing, activities waited at each handover. Management had no consolidated view of any of it - just a spreadsheet that described the plan, not the state.
The plan said what should happen. Nothing said what had.
What we built
A centralised dispatch activity and job tracking system, built around one chain: job to stage to activity, then assignment, execution, review, customer witness, project manager approval, completion. Nothing skips a link. The Project Planner imports or revises the stage-wise plan against a job - stages, activities, planned start and end dates, and the sequence they run in - and the system notifies the Project Manager rather than relying on someone to mention it.
From there the Project Manager sets the target date and decides who is involved: the responsible department, the review department, whether the customer must witness the activity, and the region department where one applies. Those decisions raise workflow requests to the department heads, who assign an actual person. The responsible person picks the activity up from a to-do list, records the actual completion date, adds comments and attachments, and submits it. The reviewer approves, reverts it for rework, or rejects it. Where witnessing is required the activity routes to the region person for sign-off first, and only then does it reach the Project Manager for final approval. When every activity across every stage is approved, the system closes the job itself.
Inside the system
Seven roles, one chain of custody, and a record of every step in it.
Planning and workflow
- Stage-wise plans imported or revised against a job, with planned dates and activity sequence
- Target date, responsible department, review department and customer-witness requirement set per activity
- Department heads assign a named responsible person and a named reviewer
- Approve, revert for rework, or reject - each an explicit action, not an implied one
- Customer witness routed to the region person before it reaches the Project Manager
- Job closes automatically once every activity across every stage is approved
Visibility and evidence
- Dashboard KPIs: total jobs, on-time dispatch, jobs at risk, dispatched this week
- Unassigned tasks, overdue activities and pending customer review surfaced as their own numbers
- Stage-wise pipeline showing how many jobs sit at each stage, so bottlenecks are visible
- Planned against actual dispatch, week by week
- Jobs at risk listed with job number, customer, dispatch date, stuck stage and days overdue
- Comments, attachments and a full lifecycle history - user, timestamp, action, status change
What it looks like
What changed
No numbers here: the client has not published figures for this system. What follows is what changed in how the work runs.
Pending work has a name against it
Every activity carries a responsible department, a responsible person and a reviewer, assigned by the department head rather than assumed. Establishing who owns something stopped being a phone call.
Follow-up moved into the system
Planning, assignment, review, revert, approval, customer witness and completion each raise their own notification, and work arrives in a to-do list. The chasing that held the old process together is no longer what makes it move.
Slippage is visible while it can still be acted on
Planned dates sit against actual dates, overdue activities are counted, and jobs at risk are listed with the stage they are stuck at and the days they are overdue - rather than surfacing at the dispatch date.
The evidence sits with the activity
Completion dates, comments, attachments, approvals and reverts are held against the activity itself, with the user and timestamp for each. The trail is a by-product of doing the work rather than something reconstructed afterwards.
Other systems we have built near this one
Energy & IndustrialSeven days of transformer design, done in twenty minutesRead the case study>
Energy & IndustrialFrom first lead to grid connection, and the warehouse behind itRead the case study>
Energy & IndustrialQuotation Approval Application for standard and BTO requirementsRead the case study>Where does your dispatch plan stop matching reality?
Stage plans, activity tracking, review and approval chains, customer witnessing - anywhere the plan is in a spreadsheet and the truth is in people’s inboxes. Tell us how yours runs today and we will tell you honestly which parts are worth putting under a workflow.