The Job Pipeline: One Number From Sold to Paid

A job here is one record with one number (the invoice number, assigned when the bid is written) and it keeps that number from the day it is sold to the day it is paid. Everything below is a different view of that one record, not a copy of it.

That is the whole idea, and it is why the calendar and the invoice can never drift apart. They are not two files somebody keeps in step. They are the same job, looked at from two directions. Change the dates and the calendar moves, because there is nothing else to update.

Seven stages, and who owns each one

Scheduled, completed, pending approval, approved, queued, invoiced, paid. Every stage has an owner and a count you can click.

The order is enforced, not suggested. Operations mark work complete. The rep who sold it signs it off. The office bills it. A job cannot jump the line, and backing one up takes a typed confirmation and writes a line nobody can erase.

That sounds strict until you have seen the alternative, which is a spreadsheet where anybody can type anything into the status column. Once one person marks a job "invoiced" that was never invoiced, nobody trusts the column, and within a month everyone is back to asking each other.

Every job, filtered by where it is

The list is those same seven stages as tabs, plus search across the job number, the builder and the address. The tabs are the stages rather than a set of saved filters, because "show me everything waiting on me" is the question, and a filter somebody has to build first is a question nobody asks twice.

The bill-check bar along the top does something less obvious, and it is worth knowing about. It reads every job’s rows against what was bid and reports the ones where the math does not hold: a mystery line nobody can explain, a bill that does not add up, a bid PDF that came back empty. It only reports. It never quietly fixes anything, because a bill that was silently corrected is a bill nobody knows to check.

The job record

One page holds the whole job: the scope, what was bid and what it is worth now, the documents, the dates, the change orders, the photos, the notes, and the record of everything anybody did to it.

It is one page rather than six tabs because the question people actually ask is never about one of those things on its own. It is "what is going on with 10240", and the answer is the scope, the money, the dates and the last thing anybody did to it, all at once.

The buttons on it are the ones this job’s stage actually allows. Nobody has to remember the rules, and nobody gets an error message after clicking: if a thing cannot happen yet, the button for it is not sitting there inviting you.

How work gets onto the calendar

A signed bid becomes a job by walking through a few questions instead of filling in a blank form.

1. 1
   The bid goes inThe signed bid, or the PDF of it. You are not typing the builder, the address or the price again.
2. 2
   The software reads itIt pulls out the details and the pricing rows and shows you all of it to check before anything is created.
3. 3
   A scope sheet is written from itThe page the crew works from, built out of the bid instead of out of somebody’s memory.
4. 4
   You pick the datesStart and finish, and the crew if you are assigning one.
5. 5
   The job existsIt carries the bid’s number and the bid’s rows, and the crew’s calendar event is written at the same moment.

Every screen on this page is the software running, captured from a demo workspace. The builders, addresses and contacts in it are invented; the plan is one we drew. More at Opulence Built.