Why not yet is a legitimate answer
Software freezes a decision. Every state, every permission, every rule about who may approve what becomes a fact the system enforces the same way every day. That is the value, and it is also the risk: if the process underneath is still being invented, the software encodes a draft and the business spends the build arguing with its own tool.
So the useful question is not whether software would help — it almost always would, eventually — but whether it would help now. What follows is the check we run in a diagnosis, including the conditions under which we say no. A checklist everybody passes is a sales document; this one has failures in it on purpose.
The three that have to be true
The process has to hold still long enough to be built. If the steps changed twice this quarter and are likely to change again, you are not describing a process, you are describing an experiment, and experiments belong in a spreadsheet where changing a rule takes an afternoon. Build when the shape has settled and the only thing still growing is the volume.
It has to repeat. The value of turning work into software comes from the same sequence running many times with the same result, so the case that happens once a year and is always different is not the case to build for. Look for the work that occupies most of the week and varies least. That is the first version.
Somebody has to be able to decide. Every build reaches a question only the business can answer: what counts as approved, who may override it, what happens to the exception. When that answer requires a committee that meets monthly, the build stalls in the worst possible place, halfway through. One person with the authority to decide is worth more than a detailed brief.
The signals that say not yet
Nobody has written the process down, and the three people who run it describe it differently. That is not a blocker, it is the first piece of work; but doing it while code is being written means building the wrong thing first and changing it second. Map it first, as its own engagement, and the build starts against something agreed rather than something assumed.
The rules change weekly because the market is still being found. A company that is still discovering what it sells should not freeze how it sells it, because every change then costs a deploy instead of a conversation. Keep the manual process for now, treat its friction as a signal about what to build later, and look again when a month passes without anyone changing a step.
The symptom is software-shaped and the cause is not. Handoffs fail because two teams disagree about who owns a step, and a dashboard makes that disagreement visible without settling it. Some diagnoses end in a process change or in a decision to stop doing something, and writing that down is a better outcome than a build that automates the argument.
What to do if the answer is not yet
Write the process as it actually runs, not as the manual describes it: the overrides, the exceptions, the step somebody skips when the client is important. That document is useful on its own, because it usually shows where the delay lives, and it is what any studio, including a different one, would need before quoting. That is why it is the first deliverable of a diagnosis.
Then pick one process, not the whole operation. A first version that carries a single complete flow on real data, with the people who use it daily working inside it, tells you more about the rest than any specification. If it changes how the work feels within a few weeks, the rest is scoping. If it does not, you found that out on the small version.