Ready by Spring

You signed in November, because November is when you have time. The kickoff call happened the first week of December, and the implementation plan the consultant emailed over ran eleven weeks, which put go-live on March 2, comfortably ahead of the season. It was a handsome PDF with your company name in the header. Week one, discovery. Weeks two through six, data migration. Weeks seven through nine, configuration and workflows. Week ten, training. Week eleven, go-live.

If you bought operations software between 2005 and 2020, you have some version of that PDF in a drawer. Here's a question worth pulling it out for: how long did the eleven weeks actually take?

The software needed your world first

That generation of software had a structural appetite: it could do nothing until it contained everything. Before it would bill a single load, it needed every customer keyed with a legal name, billing address, tax status, and default rate. Every product with a code, every hauling zone, every price. The vehicle for all this was the migration template, a spreadsheet the consultant sent in week one. Yours had 31 columns.

Now ask where that data was supposed to come from. Not from a database, because the whole point was that you didn't have one. Your 1,100 customers lived in QuickBooks under whatever spelling was on the check. Rates lived on a printed sheet with handwritten corrections, plus a few that lived nowhere except a long-timer's habit of writing "contractor rate" in the corner of a ticket. The zones lived in your dispatcher. The migration line on the plan assumed an export. What the work actually was, was interviewing your own company, one cell at a time.

The template also forced decisions the paper never required. Are "Johnson Farms" and "Johnson Farm Inc" one account or two? Which of the three rates this customer has paid this year is the default? Does the odd lime spreading work get a product code, and what's its unit? None of these questions is hard. There are just four hundred of them, they arrive at data-entry speed, and the only person who can answer them is your office manager, who fits them in around statements, because billing didn't stop for the project.

That's how weeks two through six become February.

March doesn't wait

By late February the customer master is maybe 60 percent keyed, configuration hasn't started, and nobody has been trained. So go-live slides, and the slide is the sensible call: you don't put your people on unfamiliar screens in April, with trucks stacked at the gate. The new date is "after the spring rush."

After the spring rush is July. July is the season too. The honest window is next winter, a year from the signature, and now look at the meter that's been running. The subscription has billed since December at $680 a month. The implementation fee, $14,000, is half paid and half due at a go-live that keeps receding. The consultant rolled off to other clients in March, and re-engaging her is $150 an hour. Fourteen months after signing, the count of invoices that have passed through the system is zero.

Nobody cancels it, either. Cancelling means somebody admits the $14,000 out loud. So it limps into the gray ending these projects actually get, which is worse than a clean death: the tickets stay in the carbon books, somebody keys a slice of them into the software on Fridays so a report will fill, and the operation pays for two record systems while trusting one.

The window was the price

At a seasonal operation, a system that can't bill a load in its first month will never fully go live. Not might not: the calendar does the arithmetic. Implementation effort competes with the season, the season wins every round, and the dead months are always shorter than the plan. A quarry or a custom harvester gets ten or twelve quiet weeks a year, and that generation of software routinely asked for more winter than the business has ever had.

Which reframes the owners who passed. The one who read the eleven-week plan, looked at his own calendar, and said no had priced the project at what it really cost, one office manager's entire winter, not $680 a month. And he saw the wager underneath it, a go-live date the weather got a vote on. The industry spent twenty years calling that man a late adopter. He was reading a Gantt chart correctly.

Start from the tickets, not the setup

Implementations never got faster. The starting point moved instead. Software that reads what your operation already produces doesn't need your world typed in before it can work, because your world is already written down. Every ticket in the drawer carries a customer's name as your people actually write it, a product, a quantity, a rate. The paper was the database all along. It just hadn't been read.

That's the posture Termco is built on. It digitizes the tickets as the operation already writes them, flags the ones that break a rule, holds billing rules and reference data in one structured place, and assembles invoice totals from the tickets that cleared. The reference data gets built from what the paper surfaces, and corrected as you go, instead of being extracted from your office manager in a winter-long interview before anything runs. Nothing changes at the window: the books and pens stay, nobody installs an app, and a shop that never digitized at all starts from the drawer it already has instead of an eleven-week plan.

There's a cheap way to test whether that's talk. A system built to read your paper should prove something before your next billing cycle, not after your next winter: send 10-20 sample tickets to hi@termco.ai and findings come back within 48 hours.

Either way, dig out the old PDF and read the dates against what happened. The plan wasn't dishonest. The consultant believed it, and so did you. What neither of you could deliver was the eleven quiet weeks it stood on, because your calendar belongs to the season, and the season signs nothing.