Work orders with visits, owners and a safety gate.

Walk into most busy shops in June and the work order system is a paper tag on the handlebar, a row of hooks and a service manager's memory. It works until it doesn't. A bike sits three days waiting on a derailleur hanger and nobody remembers to call the rider. Two mechanics start on the same bike. The tag says 'tune-up' but the rider was promised new pads too.

A job in Service is the single record of a repair: who it is for, what was agreed, who is doing the work, which checklist has to be done, and whether it is finished. The paper tag can still hang on the bike. The truth lives in the software, where the counter and the bench read the same thing.

Service calls these jobs and visits. A job is the repair as a whole, with its instructions and its priced lines. A visit is a block of work on a day, with one person assigned. A simple tune-up is one job with one visit. A frame that needs a warranty inspection now and a rebuild when the new frame arrives is one job with two visits.

Each job gets a number and belongs to a site. In Service today a site is a name, a free-text company name and an address, which is how the module models the customer until bike and customer records arrive. The job carries instructions, which is where 'rider says it creaks under load, check the BB and the thru-axle first' goes, and line items for labor and parts.

When the job comes from an approved quote, the lines the rider accepted are copied in, including the optional ones they said yes to, so the mechanic sees exactly what was agreed. You can also create a job directly for a walk-in who does not need a quote.

Each visit moves through four statuses: unscheduled, scheduled, in progress and completed. It has an assignee, so there is never a question of whose bike it is, and it appears on the week schedule on the day it is booked. A visit with no day waits in the unscheduled queue until someone books it.

This is the part of Service that most changes how a bench runs. A checklist template can be set to attach to every visit automatically and to be required. When it is, the visit cannot be closed until that checklist has been submitted, and a checklist cannot be submitted until its required answers are in.

For a bike shop that is the final safety check: brakes bite, quick releases or thru-axles closed, headset tight, bar and stem bolts torqued, tire pressure set. For an e-bike it is the motor, battery and display checks you want on record before the bike goes back on the road. The mechanic fills it in on the phone or the shop computer, with photos and a signature, and the rider can be given the PDF.

The checklist works from the installable field app too, which is new: answers and a completed visit are queued on the phone when there is no signal and sent in order when it comes back. It has not yet been tested widely on real phones, so try it in your back room before you rely on it.

A rider fills in your repair request form or calls, and the request lands in the Requests inbox. Someone triages it to a site and writes a quote. The approved quote converts into a job with a visit. The visit gets a day and a mechanic on the week schedule. On the stand, the mechanic clocks time against the visit, runs the checklist and completes the visit. When every visit on the job is closed, 'Bill this job' creates the invoice from the job's lines.

What you still do by hand is the status in between. There is no 'waiting on parts' or 'ready for pickup' column yet, so a bike on hold for a hanger is best left as a visit in progress with a note in the instructions, and the rider is still called when it is ready. Automatic 'your bike is ready' texts are on the roadmap.

The honest fit today is a shop that wants one record per repair, a named owner on every piece of work and a safety check nobody can skip. A shop that runs entirely off a status board by the bench will find that board is the next thing on the list, not the thing it can use today.