How do I tell whether I actually need software or whether my process is just broken?

Software compresses a process; it does not repair one

A software project takes the rules you currently follow and executes them faster, more consistently, and without forgetting. That is genuinely valuable when the rules are right. It is destructive when the rules are wrong, because the wrongness stops being visible. A dispatcher who applies a bad priority rule inconsistently at least produces obvious exceptions people notice. The same rule in code produces uniformly bad output that looks authoritative.

This is why the first question in any custom software conversation should be about the decision, not the screen. What is being decided, by whom, using what information, and how often do two competent people decide differently?

The two-week manual test

Before scoping anything, run the workflow deliberately by hand and instrument it.

• Log every input. What information did the person have in front of them when they decided?
• Log every decision and its outcome. Not just what happened, but why they chose it.
• Have a second person decide independently on a sample. Same inputs, no discussion, compare.
• Count the exceptions. How many cases required a judgment call outside the stated rule?

Reading the results

High agreement between two people and lots of repetitive clerical effort is the clean build case. The rule already exists in everyone's head; software just executes it without the labor.

Low agreement is a process finding, not a software finding. Write the rule down, get the team to actually follow it for a month, then revisit. You will usually discover the rule needs three or four conditions nobody had articulated, and those conditions are the real specification.

A high exception rate points at a third answer: automate the routine path and route exceptions to a person. That hybrid shape is what most operational AI work actually looks like in service businesses. The system handles the mechanical majority and surfaces the rest with context attached.

The case where both are true

Often the process is broken because the data needed to follow it correctly is scattered across four systems. Nobody can apply the rule consistently because nobody can see everything at once. That is a real integration problem, and fixing the process without fixing the data access will not stick.

The tell is that people describe their inconsistency as a memory or lookup problem rather than a judgment problem. When you hear I would have priced that differently if I had known they were a maintenance customer, the fix is connecting the systems, not writing a new rulebook.