Operations plans software: what it gives, what it can't

There is almost no software for writing an operations section. What exists is software for running operations — which is what a search for operations plans software turns up — and the useful question is what those systems can hand the plan and what they cannot.

The answer is narrow and worth knowing: they give you counts and timings you would otherwise guess, and they will not tell you what limits the business. That sentence has to be written by a person who has looked at the work.

What to take away

What the category contains, and what each can give the plan

Notice what none of them produces: a sentence naming what runs out first when demand doubles. That is the sentence the operations guide is built around, and it is written by hand.

The categories are not brands, but each one is sold as brands. Scheduling and dispatch, and the field service and route planning beside it, comes as ServiceTitan or Jobber. Job and project management on construction work comes as Procore. Inventory and stock control comes as Fishbowl or the inventory side of QuickBooks. Point of sale comes as Square, Toast or Clover. Maintenance and asset tracking comes as UpKeep or MaintainX. Documents and records come as Google Workspace or Microsoft 365.

None of that is a ranking, and the plan does not need the brand names. It needs the rows those systems hold.

The number to distrust

Most of these systems display a capacity or utilization figure. It is almost always derived from a setting: hours configured as available, a slot length somebody entered, a nominal crew size.

Quoting it in a plan quotes your own configuration back to you. Instead, use raw counts and show the arithmetic: jobs completed in a period, hours the asset was available, time between jobs.

A figure computed from counts survives a question. A dashboard number does not, and it will not agree with what the projections need anyway.

What to require before you rely on one

Export of rows, not charts. You need the individual jobs, transactions or movements, with timestamps, so you can compute elapsed times yourself.

Timestamps at more than one point. Order received, work started, work finished, invoice raised, payment received. Systems that record only completion cannot give you the two timings that matter most.

A definition you can read. What the system counts as a completed job, an active customer or an available hour. These definitions differ between products and they change what the number means.

History you can reach. A period long enough to show a season, and access to it after you stop paying.

Somewhere your records survive the software. Retention obligations are yours rather than the vendor's, and the plain version sits in the IRS guidance on what a business keeps and for how long: Publication 583, Starting a Business and Keeping Records. A plan that depends on a system nobody can export from has a risk in it.

The test, on a week you remember

Pick a week you can recall clearly, ideally a busy one. Pull the system's records for it and compare with what you remember happening.

Look for the characteristic gap: jobs that were rescheduled and appear once, work done as a favor that never entered the system.

Travel absorbed into job time, and the hour lost to a delivery that arrived late. Every product has a blind spot, and finding yours before you build a forecast on it separates a tool from a trap.

Then compute the two elapsed times by hand from the raw rows and write them down. Order to delivery tells you how much work must be in progress. Delivery to payment is the working capital line, and it is the number most first plans are missing.

If you have no system at all

Do not buy one to write a plan. Count for a week on paper.

Tally jobs, note the time each took, mark the ones that came back, and record when each was invoiced and paid. A week of that produces better inputs than any purchase, because it captures the exceptions software does not see, and it costs an hour a day.

Where the work is manufacturing, free help exists: the Hollings Manufacturing Extension Partnership at NIST examines exactly these questions with small producers.

What the plan should say about your systems

Two or three lines, in the operations section rather than anywhere else. Which systems run the business, who holds the data, whether you can get it out, and what happens on a day one is unavailable.

That last point is the one operators look for. A business with no manual fallback stops when the platform does. Name the fallback — a printed run sheet, a paper job board, a shared spreadsheet — and check that the roles doing it exist in the team section and can produce the unit described in the product and service section without the system running.

Common questions

Should the plan name the software we use?

Only where a system is load-bearing, and then in one line. Nobody has ever funded a business because of its scheduling tool.

Can I use a system's forecast feature for the plan?

Use its counts, not its forecast. Those features almost always project the past forward, which is the construction a reader will not accept.

We are pre-opening, so there is nothing to export. What then?

Use timings from an installer, a supplier or an operator in the trade, labeled as quotes rather than measurements, and replace them with your own counts in the first quarter.

Is it worth buying a system before opening?

Buy what the work needs on day one, not what the plan would like to quote. An unused system is a subscription and an unfinished configuration.