Job Order Management Software

A job order and a work order are the same record under two names, and this covers the lifecycle of one: it gets raised, assigned, scheduled, done, and closed with a record of what happened. The category spans maintenance teams fixing equipment, field service businesses visiting customers, and facilities teams responding to requests, and the products lean towards one of those even when they claim all three.

We sell source code you clone and run yourself, so there is nothing hosted here. Most teams should buy, and the useful part of this page is what to check.

Which kind of work order business you are

The row that most often decides the purchase is the last one on scheduling. Field service scheduling is a routing problem with travel time, skills, and parts on the van, and it is genuinely hard. Internal maintenance scheduling is a prioritisation problem. A product built for one handles the other poorly, and the demo will not make that obvious.

Closing the job is where these systems live or die

The pattern is consistent across every variant of this software. Raising work is easy and gets designed well. Closing it is done by somebody standing up, often outdoors, frequently with no signal, sometimes wearing gloves, and it is designed last.

Scheduling is where the money is, and where the promises are loudest

Automatic scheduling and route optimisation are heavily marketed and genuinely valuable at scale. They are also the feature most likely to be quietly turned off after implementation, because the algorithm does not know that a particular engineer always handles a particular customer, or that the job in the north of the city should be last because they live there.

The useful version is assisted rather than automatic: the system proposes, a dispatcher adjusts, and the constraints the dispatcher knows get captured over time. When evaluating, ask how a dispatcher overrides a suggestion and whether that override teaches the system anything.

When building is defensible

Rarely for a standard maintenance or service operation, because the products are mature and the mobile work is substantial.

The case that recurs is a work order flow embedded in a wider product: a property platform where tenants report issues and contractors respond, a warranty system where claims become jobs, a marketplace matching trades to customers. In those the work order is a component and the surrounding product is the reason for building.

What you would start from here

There is no work order capability in this stack. No jobs, no assets, no scheduling, no dispatch, no mobile app, no offline capture, and no job costing.

What the Vault template provides is the application around it: organizations as the boundary customers, sites, and contractors scope to, roles and invitations so a contractor sees only their own jobs, a Hono backend with Prisma and Kysely on Postgres, an admin app, and Stripe billing if you sell access. The calendar pack contributes scheduling views with drag to reschedule, though it has no resource model and no recurrence rule, so engineer assignment and recurring planned work are both things you would model yourself.

You would write the work order record and its states, the assignment rules, the completion capture, and the offline sync path. Take that last one seriously in the estimate: a queue of completions made without signal, replayed later, with a rule for what happens when two people closed the same job, is a real piece of engineering and it is the piece that determines whether the system is used.

Below is the tenancy, scheduling, and billing layer under all of that.