Skip to main content

Template

Work-order software specification: the filled-in template

Requests, scheduling, technicians, reports: the one page that fully describes a work-order application. Copy it, put in your request flow, and it becomes your specification — or directly your Blueprint Maker description.

This template applies the four-block method — THE THINGS, THE LINKS, THE STATES, THE NUMBERS — to work-order and after-sales tracking. It's filled in for a boiler-maintenance company: the example shows how to describe the full thread of a request, from the client's call to invoicing, without ever describing a screen.

To adapt it, follow your own flow: who calls, what gets scheduled, who goes out, what gets noted on return. The STATES block is the heart of this trade — list the exact stages a request goes through in your company, in real order, in your words.

Filled with your vocabulary, this text briefs a developer — or is submitted as-is to Blueprint Maker, which turns it into an application plan you validate, then a generated application: database, screens, dashboard and demo data.

The template to copy

My business: boiler maintenance and repair company,
3 technicians on the road, one person in the office.

THINGS tracked:
- Service requests (date received, reason, priority, channel phone or e-mail)
- Clients (name, address, phone, type private or property manager)
- Equipment (brand, model, installation date, last service date)
- Jobs (scheduled date, technician, work done, parts replaced, duration)
- Technicians (name, specialty)

LINKS:
- A request comes from a client.
- A piece of equipment belongs to a client.
- A job answers a request and concerns a piece of equipment.
- A job is carried out by a technician.

STATES of a request: received, scheduled, done, to invoice, invoiced, cancelled.

NUMBERS to see every morning:
- Requests awaiting scheduling
- Jobs scheduled this week
- Completed jobs to invoice
- Jobs per technician this month

Adapting this template to your organisation

  • No tracked equipment: if you do repairs without an equipment history (locksmithing, glazing…), remove the Equipment entity and its link — the request attaches directly to the client.
  • Service contracts: if your clients have yearly contracts with planned visits, add a "Contract" entity (start date, renewal date, number of visits) linked to the client, and an indicator "contract visits left to schedule".
  • Priorities: the example uses a priority field on the request. If urgency structures your days, spell out your levels (urgent within 24 h, standard, schedulable) — they'll become filters.
  • Reports: the "work done" and "parts replaced" fields are often enough. If your reports are richer (photos, signature), note it: the structure provides the field, the content stays free.
  • The "to invoice" state marks what remains to be invoiced — the compliant invoice itself is made in your invoicing tool, not in this application.

The matching use case

Manage service calls without losing the thread

Flow described? See the application it produces