Teaching software how the business actually works.

The clipboard was part of the system

On a visit in August, I photographed the weekly order sheets while the team explained them. Colours marked delivery days. Other rows were pickups. Some customers had standing quantities and only called when something changed.

I brought the photographs and recording back into the build and compared the paper entries with the customer export from QuickBooks. A similar name was a starting point for a question, not enough to merge two accounts or promise a delivery day.

I went back with the unresolved questions. The useful work was learning what each mark meant to the people preparing orders, driving the routes and checking the bills.

What a form would have missed

Three invoices can belong to one delivery stop. A billing account is not the same thing as a location. Grouping everything by address would make the screen simpler and the books wrong.

An empty order row does not necessarily mean nothing is due. Some customers have standing quantities and call only to cancel. The system needs to distinguish an expected order, a prepared occurrence and an accepted order. Skipping one week must not silently cancel the next.

A damaged return and a posted credit are different events. So are receiving cash and reconciling an invoice. We kept separate records and review steps for them.

The order is saved. The email failed.

If an order is accepted but its spreadsheet copy or email fails, the owner should not be told to enter the order again.

The implementation keeps the accepted order as the authoritative record. Each operational copy has its own status. A retry targets the unfinished copy; it does not resend one already marked sent. Uncertain or old email attempts can be held for review rather than blindly repeated.

The next visit changed my picture

In the September follow-up, I was describing an order as becoming real when it reached QuickBooks. The owner corrected that picture: a Monday load could already be packed on Friday, before its invoice was prepared. I needed to understand the timing of the physical work as well as the software.

We also walked through a holiday Monday moving to the preceding Saturday. I wanted that to be one dated change, without changing future Mondays or losing orders that were already accepted.

The September 8 branch adds that schedule handling, ordered driver papers and work toward QuickBooks invoice creation and correction readback. Those changes are tested but unreleased. A real controlled invoice test and the farm's review of the driver papers are still needed.

What the operating month establishes

By August 31, we had an operating-month trial behind us, as recorded in our SS26 letter. The checkpoint includes wholesale screens, a weekly board, customer review, standing-order controls, returns and picked-lot records.

That trial does not tell us how often each feature was used or what changed financially. The later visits matter because they show where the software still needs to fit the working day better.

My next job is to finish that follow-through with the team: check the invoice connection, review the printed papers and see what they can complete without my help.

Evidence at a glance

The operating-month trial is confirmed in Vertum's SS26 letter. The other rows are fixture-backed implementation checks, not customer transactions. The original checks were rerun September 6; schedule and order-copy checks were rerun September 10. Neither run retested production permissions or established adoption rates or financial results. The September invoice, schedule and driver-paper changes remain unreleased.