Evolve FM is now Zenith. We’ve brought the product under our company name. Same software, same team — new name as of September 1, 2026.
Book a demo
Zenith · Work Order Management

Work order software that refuses to guess.

Zenith is work order software that runs the whole life of a job — reported, triaged, planned, approved, scheduled, worked, verified, closed. It records downtime, repair time and crew-hours as three different numbers, tells a planner what is missing before the job is booked, and never lets a work order close on a story that does not add up.

Book a demo Explore capabilities
Bilingual EN / FR · Multi-site · WCAG 2.2 AA
3 clocks
Equipment off, repair time and crew-hours are three different questions
8 views
All, Mine, Backlog, In Progress, Approvals, Verification, Completed, Field
0 silent skips
Every refusal names the job and gives the register's own reason
EN · FR
Fully bilingual from the foundation, not a bolted-on translation
The work lifecycle

Nine work order stages. Zero gaps.

Most maintenance work dies in the handoffs — the request nobody triaged, the approval stuck in email, the closed job nobody checked. Zenith makes each handoff a stage on one work order, and each stage knows what it needs before it will let the job move on.

01

Reported

Anyone can report a fault through a plain-words portal — urgency, place, asset, QR scan and a photo, attached from the start.

02

Triaged

One queue where requests are reviewed, prioritized, merged or declined with a reason — and the requester's timeline records every step of it.

03

Raised

A five-step panel that can be minimized mid-thought and picked up later. The status is derived, not chosen — nobody picks their way around an approval.

04

Planned

Readiness before dates: parts at the right storeroom, certifications, permits, tool serviceability, a plan that can actually be issued.

05

Approved

Only what somebody might actually refuse. Each row says why it needs a signature and how long it has been waiting.

06

Scheduled

Booked against real crew capacity — a week grid of people and days, in hours or percent, with conflicts counted.

07

Worked

My Work on the desk, a scan-to-open shell in the field. A timer that writes the labour line itself, steps ticked off, photos and signatures captured.

08

Completed

Actuals recorded — labour per person per day, parts, tools, downtime, failure coding — and the gate lists anything still missing before the button works.

09

Verified & closed

A second pair of eyes, enforced: the person who did the work cannot be the person who signs it off.

The record

Eight tabs that hold the whole work order

Everything about a work order lives on the work order — no side spreadsheet, no second system for the photos, no comment thread running beside the log. Each tab carries its own count, and the open tab lives in the URL, so a link to the labour is a link to the labour.

01

Overview

The three clocks, the warranty cover callout, and “what happens next” — the actions this job can legally take right now.

02

Tasks

Steps copied from the job plan version, with safety notes. Done, or “could not” with a reason — the confirm stays dead until one is typed.

03

Labor

Per person, per day, with an overtime flag. A live timer, the estimate for comparison, and unpriced hours stated rather than hidden.

04

Materials

What was used, from which storeroom — and parts bought in for this job kept structurally apart from parts taken out of stores.

05

Tools

Special tools reserved against the job before somebody drives to the plant without one — with the crib's refusal shown if it says no.

06

Media

Photos, video, documents, voice notes and signatures — attached to the work order, so the next person with this fault finds them.

07

Failure coding

What was found, why it happened, what was done — three cascading pickers, plus suggestions argued from this machine's own history.

08

Log

One trail, not a log beside a comment thread. Notes can be marked “show this to the person who reported it”.

Three clocks

One duration column answers one of the three questions people ask

Downtime, repair time and labour are not the same number. Sixty-three hours down and three and a half hours of repair is a parts problem, not a labour one — and a register with a single duration column lets everyone guess which. Zenith keeps all three, plus start-to-finish, on every job and in the list columns.

  • Hold reasons govern the repair clock — each reason is flagged once, centrally, as counting toward repair time or not.
  • The exclusions are itemized — “Taken out of repair time: 59.5 h — Waiting for parts”, or a plain statement that nothing was taken out.
  • MTTR you can defend — waiting for a vendor stops being repair time without a technician deciding case by case.
Planning

Work order planning is not a date picker

The date is the last thing decided and the easiest. What makes a job schedulable is that the plan can actually be issued — and every one of those questions was already answered somewhere else in the system. The planning queue is where the answers are collected, in one sentence per job.

  • Readiness, in the register's own words — parts short at a named storeroom, a certification nobody holds, a permit type undefined, a tool unfit to use, a plan not in force.
  • Capacity that admits days off — a week grid of people × days in hours or percent, with utilization bands, absences, and this week's conflicts counted.
  • Backlog measured in weeks of work — at the crew's own shift patterns, with unsized work excluded rather than quietly counted as zero.
Guard rails

Refusals arrive before the click, not after it

A system that lets you press the button and then explains why it did nothing has taught you to distrust it. Zenith lists what is blocking an action above the disabled button, in plain sentences, quoting the actual step or person involved — and the same sentences appear in the field shell and in bulk previews.

  • Segregation of duties, enforced — “T. Marchand did the work, so somebody else has to check it.”
  • Completion means complete — outstanding steps quoted by their instruction, skips without reasons, holds still open, equipment still recorded off.
  • Attribution stays honest — completion is credited to the crew who did the job, not to whoever pressed the button.
Failure coding

Make the wrong answer unreachable

Validating afterwards tells somebody they were wrong. A picker that only offers what fits means they were never able to be. Cause is offered only for the problem chosen, remedy only for the cause — so the coded history that reliability analysis depends on is clean by construction, not by audit.

  • Suggestions that show their evidence — a ranked triad with citations to the actual work orders counted, never auto-applied.
  • Exempt work stays quiet — work types that do not need coding say so instead of nagging.
  • Feeds the asset — every coded closure lands on the machine's failure knowledge and bad-actor analysis.
Decision queues

Three work order queues where work waits on one decision

A grid of eleven columns cannot tell a supervisor why a job needs their signature or what is missing before it closes. These are not filtered lists — each row carries the sentence that lets somebody act without opening the record.

Planning

Approved work, and what stands between it and somebody doing it

Ordered by the latest date the job can still start and meet its deadline. Every row is either “Ready” or a list of exactly what is missing — checked against the stores that serve its own site.

Must start by 3 Sep · 3 things missing
Approvals

Work waiting for somebody to say yes, longest wait first

Only what somebody might actually refuse. Each row explains itself — “It takes equipment out of service”, “$4,200 of labour, against a $2,500 line” — and flags what must go higher.

waiting 31 h · Goes higher
Verification

Work that is done, and records that are not

Finishing the job and finishing the record are two events; without a queue, the second never happens. Each row names what is outstanding — coding, hours, an outage never closed, a second signature.

T. Marchand finished it yesterday
Work packages

A shutdown is many jobs and one thing

Several work orders planned and reported as one — the shutdown, the commissioning, the campaign across forty air handlers. Members keep their own lives, their own crews and their own gates; the package folds their numbers so the figure at the top can never disagree with the rows beneath it.

  • Built from the selection bar — tick the jobs, add to a package, name it if it is new.
  • Folded progress — done of total, crew-hours recorded, how many are overdue.
  • Raise across many assets at once — one campaign becomes a work order per machine, each with its own record.
On the tools

Work orders on a phone get no privileges and no shortcuts

The field shell calls exactly the same commands as the desktop and relays exactly the same refusals: a job that cannot be completed at a desk cannot be completed on a phone. What it adds is a way of working that suits a person standing in a plant room — scan a code, see today's jobs worst-first, and press four buttons instead of filling a form.

  • A timer that writes the labour line — press at the start, press at the end; actual time, not remembered time.
  • Evidence, captured properly — rear-camera photos, voice notes, and a real signature pad that survives a thumb wandering off the edge.
  • A field journal — everything the shell did this session, applied or refused, with the register's reason. Nothing is silently discarded.
And the rest of the toolkit

Everything a work order touches

Bulk with receipts

Hold, resume, complete, approve or package many jobs at once — with a pre-flight that shows every blocker before anything is pressed.

Warranty cover, checked

When the machine is under cover the job says so — days or usage remaining, and a claim raised before labour is charged to the wrong budget.

Calendar & unscheduled rail

The same register laid on the week or month — every chip is the work order — beside a rail of open work with no date at all.

KPI cards that can't lie

Total, open, in progress, awaiting approval, overdue — each with a six-week sparkline computed from the records themselves, not decoration.

Job plans, version-locked

Steps are copied from the plan version named on the job. Revising the procedure next year must not rewrite what somebody did today.

Stopped-work strip

Every held job across the whole register, above every view — with what it is waiting on and whether that waiting counts against repair time.

Your words, everywhere

A terminology engine renders statuses and priorities in the customer's own vocabulary — including inside the blocker sentences.

Deep-linkable everything

The open tab lives in the URL, retired paths still resolve, and any view can be copied as a link — so an email points at exactly what you meant.

Site-scoped security

Fifteen distinct permissions across work, requests, safety and permits — technicians, planners, supervisors and requesters each see their own slice.

Questions people actually ask

Work order software questions, before you book the demo

The questions that come up in almost every evaluation — answered plainly, including the ones where the honest answer is “not yet”.

How do we get centralized visibility of work orders across multiple sites?
One register, scoped by permission — not one system per site that somebody consolidates afterwards. Every site's work lives in the same register, and what you see is decided by your scope: a technician sees their site's work, a supervisor their region, a director every site at once. The eight standard views — All, Mine, Backlog, In Progress, Approvals, Verification, Completed and Field — all respect that scope, and so do the KPI cards above them, the stopped-work strip that runs across every view, and the calendar. Nothing has to be merged at month end, because it was never separated: the number a director sees is computed from the same record the site supervisor is working in.
Can we roll up work order KPIs across sites without exporting to a spreadsheet?
Yes. Total, open, in progress, awaiting approval and overdue are shown as cards with a six-week sparkline, each computed from the records themselves rather than from a nightly summary table — so a card can never disagree with the list beneath it. Change the scope and every card recomputes. Work packages fold the same way: a shutdown spanning forty air handlers reports done-of-total, crew-hours recorded and how many are overdue, all folded from the member work orders. When somebody does want the figures elsewhere, exports honour whatever search, filters and scope you had applied, and the Report Scheduler can send a saved report to a list of people on a recurrence, without anyone logging in.
Can we use our own statuses, priorities and work types?
Yes. Work types, priorities, statuses, crafts, delay reasons and failure codes are all controlled reference data you configure — not a fixed list baked into the product. A terminology engine goes one step further: if your organization calls a status something else, your word appears everywhere it is shown, including inside the sentences that explain why an action is blocked.
How do approvals work? Can we set cost thresholds?
Approval is driven by policy rather than by whoever fills in the form — the status a new job is created in is derived from its work type, cost and whether it takes equipment out of service. The approvals queue shows only work somebody might actually refuse, and each row says why it needs a signature (“It takes equipment out of service”, “$4,200 of labour, against a $2,500 line”) and flags anything that must escalate above a supervisor's limit.
Why does Zenith track three different durations?
Because they answer three different questions. Equipment off is what production lost, repair time is how long the fix actually took, and crew-hours is what it cost in labour. Sixty-three hours down with three and a half hours of repair is a parts problem, not a labour one — and a system with a single duration column lets everyone guess which. Each delay reason is flagged once, centrally, as counting toward repair time or not, so your MTTR is defensible without a technician deciding case by case.
Can technicians use it on a phone? Does it work offline?
There is a dedicated field shell — scan a code or open today's jobs worst-first, start a timer, tick steps, capture photos with the rear camera, record a signature, and complete the job. It calls exactly the same commands as the desktop and relays the same refusals, so a job that cannot be completed at a desk cannot be completed on a phone either. Full offline working is not there yet — it arrives with the native field app and the sync layer. We would rather say that than ship a queue that has never met a conflict.
How does work get created — do we have to type everything twice?
No. A work order can be raised directly, converted from a service request in one action (asset, location, description and photos carry across), released from a PM schedule with its job plan attached, or raised across many assets at once so one campaign becomes a work order per machine. Every picker points at a real source domain — assets, people, parts, locations — so nothing is retyped as free text.
Can staff and tenants raise maintenance requests themselves?
Yes, through a plain-words request portal — no maintenance vocabulary to learn and no asset codes to memorise. A requester describes the problem, says how urgent it is, picks a place or scans a QR code on the equipment, and attaches a photo. Requests land in a triage queue where they are reviewed, prioritised, merged with a duplicate, or declined with a reason — and the requester's own timeline records every step of that, so nobody has to phone the office to ask what happened. A request becomes a work order in one action, carrying its asset, location, description and photos across. Notes on the resulting job can be marked as visible to the person who reported it, which is usually the difference between a service request system people keep using and one they abandon.
Can we update many work orders at once?
Yes — hold, resume, complete, approve, or add to a work package from the selection bar. The important part is what happens underneath: a bulk action is not a loop that force-writes. Every job still passes its own gate, so you get a receipt reading “Applied to 9 · refused 2” with each refusal named and explained. Completing in bulk shows you every blocker before anything is pressed.
What stops people closing work orders with nothing filled in?
The completion and close gates. A job cannot close with steps unanswered, skips without reasons, a hold still open, equipment still recorded as off, no hours logged, or failure coding missing where the work type requires it. The blockers are listed above the disabled button in plain sentences that quote the actual step — so people fix the record rather than learning to distrust the button.
How is this different from a work order ticketing system?
A ticketing system records that somebody asked and somebody replied. A maintenance register has to survive an audit, and the difference shows at the edges: three separate duration clocks instead of one “time to resolve”, readiness checked against real stock at a named storeroom before a job is schedulable, failure coding that feeds reliability analysis, a second signature that cannot be the person who did the work, and a completion gate that quotes the actual step still unanswered. If your work is genuinely request-and-reply, a ticketing tool is cheaper and simpler and you should use one. If somebody will one day ask you to prove what was done to a machine and when, that is what this is for.
Can contractors be assigned work, and can we control what they see?
Yes. Contractor work orders follow the same lifecycle as your own crew's — assigned, tracked, completed with evidence, and verified before close. Vendor records carry trades, rates, insurance and certifications with expiry dates, and notes on a job can be marked internal or visible to the requester, so the conversation between tradespeople stays separate from the answer somebody outside has been waiting on.
Does it capture what the job actually cost?
Labour is recorded per person, per day, with an overtime flag — sixteen hours in one box cannot be costed, because it does not say whether that was two people for eight or one person over two days at overtime. Parts are recorded against the storeroom they came from, with parts bought in for the job kept structurally separate from stores issues. Where a rate is missing, the unpriced hours are stated rather than quietly folded into the total.
Why is failure coding done with cascading pickers?
Because validating afterwards tells somebody they were wrong, while a picker that only offers what fits means they were never able to be. The cause list is derived from the problem chosen and the remedy from the cause, so invalid combinations are unreachable and the coded history reliability analysis depends on is clean by construction. Zenith also suggests a likely triad from this machine's own history — ranked, with citations to the work orders it counted, and never applied until somebody chooses it.
Is it bilingual, and does it handle multiple sites?
Both, from the foundation. Every screen, status, notification and refusal sentence has full English and French parity — including dates, plurals and number formats — with en-CA and fr-CA as first-class locales rather than a translation layer. Site scope is built into the data model and the permissions, so a technician sees their site's work, a supervisor their region, and a director can compare across all of them without being able to edit any of it.
Can we get our data out, and report on it?
Yes — exports honour whatever search, filters and scope you currently have applied, so what you get is what you were looking at. Any view can be copied as a link, and the open tab lives in the URL, so an emailed link points at exactly what you meant. The Report Scheduler can then send a saved report to a list of people on a recurrence you set, without anyone logging in.
Enterprise foundations

Numbers that agree with each other

A page whose own figures appear not to add up does not get believed about anything else. The discipline behind this module is that every number is computed from the same records the list shows — and anything that cannot be told truthfully is not shown at all.

Derived, not stored

Clocks, capacity, readiness, KPI history and progress steppers are computed from the records themselves — a card cannot disagree with the list beneath it.

The register decides

No screen has privileged commands. The field shell, the bulk bar and the create panel all go through the same gates and relay the same refusals.

Bilingual by birth

Full en-CA / fr-CA parity on every screen, every status and every refusal sentence — including dates, plurals and number formats.

Accessible to everyone

WCAG 2.2 AA as a build rule: no drag-only interaction anywhere, labelled controls, and full keyboard reach through every queue.

Designed around ISO 14224 · Reliability data EN 15341 · Maintenance KPIs ISO 55000 · Asset management WCAG 2.2 AA
See it with your own work

Bring the job that took three systems and five phone calls.

We'll run it end to end in Zenith — reported, planned against real stock and real capacity, approved, worked on a phone, coded, verified and closed — and you'll see every number it leaves behind.

Book a demo Talk to our team
Zenith · Work Order Management Part of the Zenith maintenance & asset operations platform

Standards are named by number, title and scope only. CSA and ULC publications are paywalled — read the standard itself before building a compliance programme on any summary.