For mobile bike repair

You start with six stops across town. Two are tune-ups at a corporate campus, one is a flat on a cargo bike outside an apartment building, one is a new customer who described the problem as 'gears are weird', and two are regulars. The order they booked in is not the order you should drive them in, and one of them needs a 12-speed chain you are not sure is in the van.

At the curb, the problems are different from a shop. The customer is standing next to you, so the conversation about the extra work happens right there. There is no card terminal on a counter. The signal in the parking garage is one bar at best. And when you get home, you still have to write up what you did at each stop, send the invoices you did not collect on, and work out what to restock for tomorrow.

Mobile repair lives or dies on drive time and parts. Every extra mile between stops is unpaid, and every trip back to the shop for a part is a stop you did not make. The software that helps is the software that plans the route, knows what is in the van, and lets you finish the job, including payment, before you close the back doors.

Today a mobile day in Service is a set of visits. Each job is at a site, which is the customer's address and name, and each visit has a day and a mechanic. The week view shows every visit by day, the just-mine filter shows a mechanic their own, and the Today page is the crew's list for the morning. A visit is moved to another day or another person with a select, not by dragging, and there is no hour grid, so the order you drive them in is still yours to work out.

The Service plan treats a van as a stock location, just like the shop's back room. Parts are received into the shop, transferred to the van, and consumed on the job they go into. A reorder point on the van tells you what to pull from the shop shelf before tomorrow's route. That is on the roadmap for the inventory phase.

Routing is planned with start and end points per mechanic, real drive times, and a map view of the day. Location is planned to work in the foreground: when you open the job on your phone, the app will record a check-in. There is no background GPS tracking, and live location of a van on a map would come from vehicle telematics, which is part of the planned fleet features, not from your phone.

The field app is a web app you install to your home screen, not an App Store download, and it is new. In the parking garage with one bar, it keeps working: checklist answers and marking a visit complete are held on the phone and sent, oldest first, when the signal comes back. With no signal it shows a plain offline page rather than a stale job list. Web push for added or moved stops is planned and not built yet.

Because the field app is web only, there is no Tap to Pay and no Bluetooth card reader. The planned way to take payment is a Stripe payment link or a QR code on your screen that the customer pays on their own phone, or entering their card details yourself. Pay links, QR codes and card entry are on the Service roadmap and cannot be used today.

What you can do today is run the inspection at the curb, have the customer sign it on your screen, close the visit and bill the job as a numbered invoice. Sending the invoice marks it sent but does not email it, so the customer pays you the way they do now, and an admin records the payment against the invoice, including part payments. The PDF of the completed checklist is a clean record of what you found and what they agreed to.