Service checklists every mechanic fills in the same way.

Every shop has a standard for a tune-up. The trouble is that it lives in the head of your best mechanic, and the new hire in April does it differently. One checks chain wear with a gauge, one eyeballs it. One torques the stem bolts, one does not. The rider cannot tell until something comes loose.

Service checklists put your standard into a template. You build it once in the checklist builder, and every mechanic fills in the same questions in the same order, with photos where you want evidence and a signature where you want someone to put their name to it. When it is done, the rider gets a PDF showing what was checked.

Checklists are live in Service today, and they are wired into the work. A template can attach itself to every visit and be marked required, and then the visit cannot be closed until the checklist is submitted. It is the same checklist engine that erp.io's other modules use. Service does not ship starter templates, so you build your own tune-up, safety and e-bike checks; the free templates on this site are a good place to start.

A mechanic opens the checklist on the phone or the shop computer and works through it. Every answer type has a real control: a number field for chain wear, a camera button for photos, a signature pad for a finger. Each answer saves as it is given, so a mechanic who gets pulled away to the counter does not lose the half-finished check. New: installed as a web app on the phone, it keeps working with no signal. Answers and submissions are queued and sent oldest first when the signal returns, and repeated edits to one answer collapse into one. That offline mode has not yet been widely tested on real phones.

Required answers are enforced. If you mark the torque check and the brake test as required, the checklist cannot be submitted until they are answered. That is the difference between a checklist and a suggestion. A submitted checklist can be read back by anyone with permission, with every photo and signature in place.

Templates are versioned. Every time you save a change to a template, Service keeps the previous version exactly as it was. Answers point at questions by a permanent id, so renaming 'Chain wear' to 'Chain wear (%)' or reordering options never changes what an old submission says.

The checklists report shows every submission of one template, filtered by date and status, on screen and as a CSV. Columns are keyed by question, not by label, so a template that asks 'Condition?' twice, once for the front brake and once for the rear, exports as two columns instead of one broken one. An answer given against an older version of the template still lands in the right column, under the option label the mechanic actually picked.

That makes the CSV useful for real questions. How many tune-ups found a chain past 0.75 this spring? Which mechanic flags worn pads most often? How many e-bike checks logged a battery below a given voltage? Open the CSV in a spreadsheet and count.

Each submission also renders as a PDF with the photos and signatures drawn in. That is the record you hand the rider, keep for a warranty claim, or file when a fleet customer asks for proof that their bikes were safety checked.

A checklist can be published to a public link for people outside the shop: a pre-ride inspection form for a group ride, a rental return check a customer fills in, or a simple repair request. You choose whether anyone with the link can submit, or only someone who confirms a six-digit code sent to their email. You can set when the form opens and closes, which websites may show it, and whether photo uploads are allowed at all. Uploads on public forms are off by default and capped when turned on.

Public forms are protected against spam with Turnstile, and they fail closed: a published form refuses submissions until spam protection is configured, instead of quietly becoming a spam inbox.

Who can do what comes from the person's erp.io workspace role, which maps to named permissions: build templates, fill them in, view other people's submissions, export, and publish to the public internet. Crew can fill in checklists; publishing stays with admins by default. Viewing is not editing: someone who can read a colleague's checklist still cannot change, submit or discard it.