Into the Field

The question that shaped this section: what a deal record is missing when the work does not happen at a desk. A deal has an amount, a stage, a contact and a close date. Work that happens at a property has an address, a crew, a set of trades, a sequence of stages that are physical rather than commercial, and several hundred photographs. None of that fits on a deal, so a business whose revenue comes from going somewhere and doing something ends up running two systems: a CRM for the sale and a field application for the job. Between them sits a spreadsheet that reconciles the two, maintained by whoever is least able to refuse, and a phone full of photos that nobody can find six months later when a warranty question arrives. The buyer is paying for both products and is doing the integration work by hand. I considered building the field side as its own module with its own records, which is the shape most products in this space have, and rejected it. The reason is worth stating plainly because it is the single most consequential decision in this part of the product. If a job is a new kind of record, then every capability already built has to be extended to know about it. Invoicing has to learn about jobs. File storage has to learn about jobs. The mailbox threading has to learn about jobs. Calendar events, automations, the report builder, the audit log, the export, all of it. That work is never finished, and the parts that lag are invisible until an operator goes looking for a feature on a job and finds the version of the product from eighteen months ago. So a job in Canopy is a deal with a job record attached to it. The commercial object and the physical object are the same object, seen from two sides. The consequence is that every money, file, email, calendar, automation and reporting capability in the install works on a job from the first day it exists, because all of them already key on the record a job is built on. Nothing about field work is a separate island that has to be colonized feature by feature. When I ship an improvement to invoicing, jobs get it. When I ship an improvement to the report builder, jobs get it. That is not a convenience for me. It is the reason the field half does not rot. On top of that sits the job file itself: one piece of work at one address, carrying the customer, the property, the trades involved, the priority, the owner, and a milestone strip that writes its own history as the work moves through it. The history being automatic is the load-bearing part. A status field that somebody has to update is a status field that is wrong, and it is wrong in the specific direction that flatters whoever last touched it. A strip that records the transition when the transition happens gives the operator a timeline they did not have to build and cannot accidentally launder. Six months later, the question 'when did this actually get to final inspection' has an answer. The photo wall is built for the roof rather than for the desk, and two decisions in it took more thought than the rest of the job file combined. The first is ordering. Photos are ordered by when they were taken, not by when they arrived, and the difference matters constantly in practice. Field photography does not upload as it is shot; it uploads whenever the phone next has signal, which means a morning of work can land in three batches in an order that has nothing to do with the sequence of the work. Ordering by arrival produces a gallery that tells the story backwards and out of order. Ordering by capture time produces the sequence the work actually happened in, which is what somebody reading the file later is trying to reconstruct. The second decision is what happens when there is no signal, and this is where most field applications quietly fail their users. A roof, a basement, a rural property, a steel building: these are the normal working conditions, not the edge case. A photo taken there is either lost, or it is held hostage by an application that has to stay open and in the foreground until coverage returns. Both outcomes put the burden on the person on the roof, who has the least attention to spare. In Canopy the photo is written to the phone the moment it is chosen, and it uploads itself when coverage comes back, whether or not the application is still open and whether or not the person who took it remembers. Shoot the roof, drive back into range, and it arrives. The crew member's job is to take the picture. That is the whole of their job. The honest exclusion here: this is a queue, not a guarantee against a lost phone. If the device is destroyed before it next sees signal, the photos on it that never uploaded are gone, the same way they would be gone from any camera. What the queue removes is the far more common loss, which is the photo that was taken correctly and never made it anywhere because an application was backgrounded at the wrong moment. The whole admin installs on a phone as an application, with nothing to download from a store and no second password. That is deliberate on both counts. A store download is an approval process, a review queue, and a second artifact to keep in step with the web version, and the field crew would be running a different build of the product from the office by the second month. Installing from the site means there is exactly one product, and installing changes where it lives rather than what it can do. No second password matters because the alternative is a crew member standing on a roof in the cold being asked to remember a credential they use twice a month, and the predictable outcome of that is a shared login written on the inside of a truck door, which is worse for the buyer than anything the password was protecting against. Documents, emails and texts file against the job, which closes the loop the two-system arrangement leaves open. The permit is on the job. The customer's email asking about the change order is on the job. The text confirming the crew's arrival is on the job. The photographs are on the job in the order they were shot. And because the job is a deal, the invoice and its payments and the delivery cost are on the same record, so the question 'what did this job actually make us' is one record away rather than a reconciliation. The operational consequence the buyer feels is the end of the spreadsheet in the middle. There is no reconciliation step, because there are not two systems to reconcile. The sale, the work, the evidence of the work, the invoice and the margin are one continuous record that the office and the field are both writing to from the tools they each already carry. For a business whose money is made at an address rather than at a desk, that is the difference between a CRM they tolerate and a file they actually run the work from.