← All posts
Scheduling

A work order from accepted quote to approved hours

Six states, one of them irreversible, and a completion that has to survive one bar of signal. What a work order carries, what it refuses, and what an accepted quote hands it.

The Closepact team9 min read

TL;DR

The work order is the unit of everything in a service company: it is what is scheduled, what is driven to, what is signed for, and what becomes money. This is what one carries, the six states it moves through, why completion is a single request, and — stated plainly — which part of "from quote to done" is automatic and which is still a person's job.

What a work order carries

More than a calendar entry, and each field earns its place.

Who and where. A customer, optionally a named contact, and a service address. The address is not a string on the job; it is a record on the customer, with coordinates and an optional geofence radius between 10 and 5000 metres, plus access notes — the gate code, where the key is. The coordinates and the radius are set in the panel, where the coordinates can be fetched from the street address via OpenStreetMap. The access notes are shown to the office and to the worker booked on the job, and to nobody else. The crew reads the same address every time, and it is the address the clock-in is compared against.

What. A title, a description, and services chosen from a catalogue. A catalogue service carries its own duration, price, unit label, VAT rate and whether it counts as deductible labour. That last one matters: a cleaning is 25 % VAT, a passenger transport is 6 %, and one rate per company cannot describe a firm that does both.

How it is priced. Hourly, a fixed agreed price, or per unit — three windows rather than two hours. ROT or RUT marking sits on the job, with an optional share when two owners of a property claim half each.

When. A planned start and end, an estimate in minutes, and optionally an earliest and latest start for work with a window rather than a time. Later, an actual start and end taken from the clock.

How it got here. A source field, so the reports can tell you where your work comes from.

The six states, written out

Booked, scheduled, in progress, completed, invoiced, cancelled.

The permitted moves are written out one by one rather than inferred from the order of that list, because the order is not the rule. A scheduled job can lose its last assignment and fall back to booked. A completed job can never become in-progress again.

Two transitions matter more than the rest.

Completed to invoiced, and nothing else. There is no path back from completed. Reopening a finished job is how the same work gets billed twice.

Cancelled is reachable from anywhere before the work is done, and from nowhere after. Cancelled work is excluded from conflict checks, from the invoice basis list and from the reports, because it is not work and it cannot become money.

The checklist, and why it blocks

A checklist item can be marked required. A required item that is not ticked stops the job being completed.

That is the entire difference between a checklist and a note. If completion ignored it, the list would be decoration and the dispute it exists to prevent would happen anyway. Instead the refusal names the open steps — "required steps are not done: photograph before, photograph after" — because a worker told only "not finished" has to hunt through a list on a phone in the rain.

There is a second, subtler rule. When a step is ticked, the person and the time are stamped on it, but only when the value actually changes. The field app sends the whole list it holds rather than a diff, so a completion at four in the afternoon echoes back every step ticked at nine that morning. Restamping those would move the whole day's ticks onto whoever closed the job, at the minute they closed it — and the checklist is the evidence that the job may be called done at all. That is exactly the dispute it exists to settle, lost.

Completion is one request

The field app sends the ticked checklist, the materials used, the customer's signature and any corrected times in a single request, because the van has one bar of signal and four requests mean three of them fail. That one bar is needed: unlike clocking in and out, a completion does not queue offline.

So all of it commits or none of it does. Half a completion — signature stored, materials lost — is worse than none, because the invoice is built from what landed and nobody looking at it afterwards can tell that something did not arrive.

Inside that transaction, a handful of decisions worth knowing about:

The row is locked and read again. Two phones in the same van, or one phone retrying after a timeout it never saw the answer to, would otherwise both pass the status check and the second would write a second signature over the first.

A second completion is refused, not repeated. It comes back as a conflict naming when the job was completed. Writing again would append a second signature file and announce the job to invoicing twice, which is how one visit becomes two invoices.

The signature is sniffed from its bytes, not from what the upload claims. PNG or JPEG, or it is refused. A signature is only worth storing if it is the picture we say it is; anything else is a file that looks like evidence until the day somebody opens it in front of a customer who disputes the invoice.

Times: whatever was clocked stands unless the app corrects it. The clock is right more often than memory is, but a worker who forgot to start it has to be able to say so. If nothing was ever clocked, the start stays empty rather than being invented, because invented minutes end up on an invoice.

And then it is worth something

A completed job becomes an invoice basis immediately. Three rules hold that document up.

Only approved hours are billable. Reported time that nobody has signed off does not appear among the hours that do — but it is not silently dropped either. It comes back as a named warning with the minutes and the number of entries, because an invoice short by a day is a conversation with the customer and the office should have it before sending, not after.

Labour and materials are always separate lines. Always, because a ROT or RUT deduction applies to one and never to the other. Materials cannot carry a deduction however the row is flagged; if somebody ticked one by hand, the flag stays visible on the line rather than being silently corrected.

Nothing is rounded twice. Each line is rounded once, in öre, and the totals are sums of rounded lines — which is what the invoice written from them will do. A basis that disagrees with its own rows by an öre is one nobody trusts twice.

The deduction itself is 30 % for ROT and 50 % for RUT, computed on the eligible labour including VAT, because that is what the rule says and computing it on the net would understate every deduction by a fifth. The per-person annual ceiling is not applied, and cannot be: it depends on what every other company has already claimed for that buyer this year, which this system cannot see. Nothing is sent to Skatteverket from here, because Skatteverket has no API for the claim: the invoicing module builds Skatteverket's import file from paid ROT and RUT invoices, and you read it into the e-service Rot och rut – företag and sign with BankID there. The calculation is built.

The part that is not automatic

Being direct, because this is the sentence most vendors skip.

An accepted quote does turn itself into a work order to be planned, on the proposals module's Väx and Pro tiers with the scheduling module beside it. It happens when the customer accepts, or by a button on the quote; each organisation chooses, and automatic is the default. The job carries the customer, the contact who accepted, the service address, the title, and the accepted lines — only the optional ones the customer ticked — with quantity, price, discount and VAT rate, plus the ROT or RUT choice. If there is no address to pick, the job says so. It happens once per quote, and the seller gets an email.

What is not automatic is the rest. Nothing schedules the job: a person plans it, because a planner knows things the system does not. Raising a quote from a job is not built. And for a system outside Closepact, an accepted quote can still leave by webhook (quote.accepted), through the API or as an export.

The other direction — completed job to invoice — is built, in the sense that the basis is produced and exported. Whether it becomes an invoice inside the system or a CSV a bookkeeper imports depends on whether you bought the invoicing module.

What to set up before your first real job

  • Checklist templates per service. Mark required only the steps you would actually stop work over. A list where everything is required is a list people tick without reading.
  • A geofence radius on the addresses you visit repeatedly. Without coordinates and a radius there is no fence, and the clock-in records no verdict rather than a false one. Both are set on the address in the panel, and the coordinates can be fetched from the street address.
  • The ROT or RUT marking on the job, not on the invoice. It is decided in the field, by what was done.
  • A billing rate on every employee. Labour is billed at the billing rate, which is kept apart from what the hour costs you; people set up before the two were split start with the billing rate equal to the cost, and the basis warns about hours billed at cost. Approved hours with no rate are billed at nothing, and the basis will tell you so by name — but only after the work is done.

Further reading

Keep reading

Want to see this with your own jobs?

Book a 20-minute demo. We set up one of your own jobs before the call: a quote, a week on the schedule or an invoice.

Book a demo