Job management software for service businesses, being developed toward a connected operating system for service operations.
One record per job, carrying its own history from the customer's first request through to payment. The office, the technician and the customer all look at the same thing rather than four versions of it.
Being built nowWhere jobs, customers, technicians, payments and history sit in one operating model — and where an intelligence layer becomes possible because the operational data underneath it is finally trustworthy.
Direction, not a shipped featureService businesses run real operations on tools that were never meant to hold them. Nobody chose this — it accumulated, one workaround at a time, and by the time it hurts there is no single place to go and fix it.
The people using it are on site, often on a phone, usually in a hurry. If capturing the data costs more time than it saves, it will not be captured — which is why most field software fails quietly rather than loudly.
So the design rule is simple: every step must produce structured data as a side effect of doing the work, never as an extra admin task afterwards.
Tap any stage to see what the job looks like at that point and what data it has produced.
The request arrives however the customer prefers — a call, a message, a walk-in — and lands as a structured intake rather than a note someone has to remember to act on.
Customer record, request detail, timestamp, channel
The request becomes a job with a scope, a customer, a location and a reference everyone can use — the office, the technician and the customer are now talking about the same object.
Job ID, scope, site, priority, created-by
The job is assigned to a technician or team with the schedule attached. Ownership stops being a question anyone has to ask.
Assignee, scheduled window, skill match, workload
Updates happen where the work happens — on a phone, in a few taps, with photos where they matter. The status is current because updating it is easier than explaining it later.
Status transitions, time on site, notes, evidence photos
The customer sees what was done and confirms it. The dispute that would otherwise arrive at invoicing time gets resolved here instead, while everyone still remembers the detail.
Approval record, sign-off time, variations agreed
What is owed is attached to the job that earned it, not reconstructed monthly from memory and bank statements.
Amount due, payments received, outstanding balance, ageing
The job closes into a history that is actually queryable — by customer, by site, by asset, by technician. This is the asset that compounds, and the reason the intelligence layer becomes possible at all.
Full job record, duration, cost, recurrence signal
Design previews of how the product is intended to work. These are concept screens, not screenshots of a deployed application.
When the built screens are ready these are replaced with real product screenshots. Until then they are labelled as concepts on every frame, so nothing here reads as a deployed feature.
Everything below is roadmap. None of it is built, and none of it is worth building until the job history underneath is complete and honest.
Customers asking where their job is and getting an accurate answer without anyone reaching for a phone.
Updates generated from the job's own state transitions rather than typed out again for the customer.
Assignment that accounts for location, skill and real durations drawn from history rather than optimism.
Flagging the jobs likely to slip while there is still time to do something about it. Requires a meaningful history first.
Which work is actually profitable, which customers cost more than they pay, where the month really went.
The order matters. Prediction built on incomplete job records produces confident nonsense — which is exactly the failure this whole practice argues against.