Elevon in ForbesOne Board for the Whole Shift, No Assignment Without the Qualification
Operational maintenance planning is a shift-long negotiation between requests, people, qualifications and bays. We prototyped it as one screen with a live timeline: drag a job onto someone without the required qualification and the system blocks it and says why. Four role views over the same shift, all on sample data, sent as part of the offer.
Client
Transport company
Industry
Public sector & safety
Solution
Dispatch board for operational maintenance planning (prototype)
Deployment
Interactive prototype
Part of an offer, not a delivered project. One sample shift, invented employees and units, no connection to any real system.
The Brief
Operational maintenance planning is not a scheduling problem you solve once in the morning. Requests arrive from the maintenance system, staffing comes from the attendance system, bays and lifting equipment are limited, and each employee has a specific set of qualifications. Then something is reported from operations mid-shift and the whole plan has to move.
In a document, all of that reads as a paragraph about constraints. In practice it is a sequence of small decisions made under time pressure, and the only question that matters is whether the tool helps or slows the dispatcher down. That cannot be answered by a feature list; it has to be tried.
The brief also spanned four roles: the shift lead preparing the shift, the dispatcher running the board, the employee reporting work from the shop floor, and everyone who wants to see afterwards how the plan compared to reality. Four different screens over the same shift, which is exactly the kind of scope that is easy to underestimate on paper.
How We Designed It
The design principle throughout: a rule the dispatcher has to remember is a rule that gets broken. Every constraint in the prototype is enforced at the moment of the action, with the reason visible on the spot.
Validation at the moment of the drop
Blocks snap to fifteen minutes as you drag them. Drop a job on someone who does not hold the required qualification and the system refuses the assignment and explains which qualification is missing. Collisions are detected and the shift's time fund is recalculated on the spot.
The suggestion shows its work
"Suggest assignment" does not drop an answer on the board. It walks through the steps it took and offers three candidates, each with a score and the reasons behind it. The dispatcher stays the one who decides, which is the only version of this feature that survives a real shift.
One dataset, four views
Shift preparation, the dispatch board, the employee terminal and the shift overview are four views of the same shift, switchable by click or with keys 1 to 4. Each role sees its own screen, and nobody has to reconcile two versions of the same plan.
How Delivery Would Run
The prototype is one screen with four views. Shift preparation consolidates what exists before the shift starts: requests from the maintenance system, staffing from the attendance system, the centre's bay capacity and the shift's time fund. The dispatch board is the working view: a timeline for five employees, operation blocks in four states, a current-time line, drag and drop, the request queue, the assignment suggestion and a button that simulates a report coming in from operations mid-shift.
The remaining two views close the loop. The employee terminal is where the work is reported: card login, the list of assigned operations, start, pause and complete with the time measured against the norm, a checklist, and the report written back into the maintenance system. The shift overview shows KPIs and plan versus actual per employee, which is what turns the board from a planning tool into a record of what happened.
Delivery would follow the risk. The board carries almost all of it: drag and drop, the qualification rules, collision detection, the time fund: so it would be built and tried first, on one real shift in one centre. The terminal is the second step, because it is the part that depends on integrations: requests and write-back to the maintenance system, staffing from attendance. Preparation and the overview are largely read-only views over data the first two steps already produce.
What this looks like in practice
The client opens the board and tries the thing the whole system stands or falls on: drag the unassigned critical job from the queue onto an employee who does not hold the qualification for it. The assignment is refused with the reason. Drop it on someone who does, and the block snaps into the timeline, the collision check runs and the time fund updates. Then they press the button that simulates a report from operations and watch a new request land in the queue mid-shift.
Dispatch board
Anonymized preview, running on blind sample data.
What the Prototype Proves
This is a prototype, so there is nothing deployed to report on. What the client can check by clicking is this.
Four role views over one shift, switchable by click or with keys 1 to 4
An assignment without the required qualification is blocked, with the reason shown
Drag and drop with a fifteen-minute snap, collision detection and a recalculated time fund
An assignment suggestion with three candidates, each with a score and its reasons
A simulated report from operations, so the client sees an unplanned job arrive mid-shift
A shop-floor terminal: card login, start, pause and complete against the norm, a checklist
A shift overview with KPIs and plan versus actual per employee
The two integration points named on the screens: the maintenance system and attendance
Why We Send a Prototype, Not a Deck
A dispatch board is a tool for someone under time pressure. Whether it helps depends entirely on the small interactions: how a block moves, how fast a mistake is caught, how the tool behaves when the plan breaks. A written specification describes the rules; it cannot show you how they feel when you are the one dragging the block.
The prototype also settles an argument that otherwise runs through the whole project: what the AI suggestion is allowed to do. Showing three scored candidates with reasons, instead of one automatic assignment, makes the answer concrete: the system prepares the decision, the dispatcher makes it. That is much easier to agree on when you can see it than when you are reading about it.
And it makes the scope honest. Four role views is a bigger project than a single board, and both sides are better off knowing that before a price is agreed rather than halfway through delivery.
Want a similar transformation in your organization?
Let's talk about how Elevon can help your team too.
Book consultationRelated case studies