Most field service processes have three artifacts: something the technician writes, something the office assembles, and something the client receives. Information is copied twice, and each copy is a place for work to disappear.

The alternative is one artifact that serves all three purposes. The record the technician creates in the field is the record the client is billed from.

What the report has to hold

For a report to carry that weight it needs more than a text box.

It needs the event date, distinct from the date it was filed. Reports get submitted late, and pricing has to key on when the work happened. This is the field most systems get wrong by defaulting to submission time.

It needs photographs, dated at capture. A photograph is the only field observation that cannot be argued with later.

It needs structured entries rather than prose. Readings, counts, states, completion of specific checklist items. Prose cannot be queried, cannot be compared across visits, and cannot drive a billing rule.

It needs a repeating section for extra items, with each row carrying its own receipt where a cost was incurred. That section is where unplanned work lives, and unplanned work is the part most likely to go unbilled.

And it needs to know which property and which agreement it belongs to, because those determine the rates.

What happens on submit

Submission is where the transformation occurs. MapleConcierge resolves the property's active agreement, prices each item from the contracted rate table using the event date, applies the contracted markup to pass-through costs, and creates a draft invoice addressed to the owner in the billing system.

Several boundaries are deliberate in that sentence.

Rates come from the agreement, never from code. Nothing is priced by a default.

The draft is a draft. Nothing is emailed to the client. A person reviews and sends.

The caretaking system sends line items only. It does not compute tax, subtotals or totals. The billing system is the single authority for those, because two systems computing tax independently will eventually disagree on an invoice that has already gone out.

And a report can produce exactly one invoice, enforced by a database constraint. A retried submission after a timeout returns the original rather than creating a second.

What the technician sees

None of the above should be visible in the field. The technician sees a form: what property, what date, what happened, photographs, and any extras with receipts.

That is the design constraint that decides whether the whole thing works. A report format that takes fifteen minutes to complete on a phone in a cold driveway will be filled in from memory that evening, at which point the photographs are missing and the extras are approximate. The capture has to happen at the property or the data is not worth having.

What it changes

Three things, all measurable.

Billing stops depending on memory, so small recurring items stop going unbilled.

The lag between work and invoice collapses, because assembling the invoice is no longer a separate task waiting for someone's time.

And every charge has evidence behind it. A client query resolves to a dated report with photographs and receipts, in a click, instead of a search through five weeks of notes.