Most companies do not have a “lack of software” problem.
They already have an ERP. They have a CRM. They have accounting software, spreadsheets, customer portals, vendor portals, shared drives and industry-specific systems.
And people still spend hours every week copying information from one place to another.
That is not a contradiction.
It is a predictable consequence of how business software is bought.
Each system owns a part of the business. The CRM owns the opportunity. The ERP owns the order. The field-service platform owns the work order. The vendor portal owns the supplier response. Accounting owns the invoice.
But the business process does not stop at the boundary of each application.
It crosses all of them.
That is where manual work survives.
The work is usually in the handoff
Consider a simple purchasing process.
The ERP says a purchase order is open.
The supplier replies by email with a PDF acknowledgement.
The acknowledgement changes the promised delivery date.
A buyer notices the change, updates a spreadsheet, opens the ERP, finds the PO, updates the date, checks whether production is affected, and perhaps tells someone else.
Nothing is “offline.”
Every step is digital.
But the workflow is still manual.
The same pattern appears in service operations:
- a customer request creates a work order;
- someone checks whether parts are available;
- a PO is created if they are not;
- the technician is scheduled;
- the field team completes the job;
- documents and labor come back;
- someone checks whether the job is ready to invoice.
Again, there may be software at every step.
The repetitive work is the translation between the systems.
A useful diagnostic question
Instead of asking:
What new platform do we need?
ask:
Where does a person repeatedly translate the output of one system into the input expected by another?
That question tends to reveal much smaller and more valuable opportunities.
Typical answers sound like:
- “We download this report every morning and compare it with another one.”
- “We have to check the customer portal before we can close the job.”
- “The supplier sends confirmation by email, then we update the ERP.”
- “The technician closes the work order, but accounting still has to check five things.”
- “We submit the warranty claim in the OEM portal and then track payment separately.”
- “The spreadsheet is the only place where we know what is actually waiting.”
Those are not vague “automation opportunities.”
They are already bounded workflows.
Spreadsheet glue is one of the strongest signals
Spreadsheets are often blamed for operational problems they did not create.
A spreadsheet frequently exists because no single system represents the whole workflow.
The ERP may know that a PO is open.
The supplier portal may know that it has been acknowledged.
The warehouse may know that it was received.
Accounting may know that the invoice is blocked.
The spreadsheet is where the team reconstructs the missing process state:
- waiting for acknowledgement;
- supplier date changed;
- ready to receive;
- received with discrepancy;
- waiting for invoice;
- ready to close.
In that situation, the spreadsheet is not merely a bad database.
It is evidence that the workflow itself has no home.
Email is often an unofficial workflow engine
Operational email is full of state transitions disguised as conversation.
“Please confirm.”
“Still waiting.”
“Can you resend the PO?”
“Quantity does not match.”
“Technician forgot the signed report.”
“Claim rejected — missing photo.”
“Vendor says delivery moved to Friday.”
When those messages follow a recurring pattern, email is not just communication.
It is carrying workflow state.
That does not mean the business should replace email.
It means a small system may be able to detect the routine state changes and keep the process synchronized without forcing a person to re-enter them.
The answer is usually not to replace the ERP
A narrow handoff problem rarely justifies replacing the core system.
Replacing an ERP, CRM or vertical platform changes the entire risk profile:
- historical data must move;
- users must be retrained;
- permissions must be recreated;
- integrations must be rebuilt;
- reports must be reproduced;
- years of process decisions must be rediscovered.
A smaller approach is often better:
keep the systems of record and build only the missing coordination layer.
That layer may:
- read a new record or document;
- identify the related record in another system;
- normalize the relevant values;
- compare them against business rules;
- update a workflow state;
- write back a safe change;
- send only exceptions to a person.
The existing systems keep doing what they are good at.
The small system handles the gap.
Scope the handoff, not the department
“Automate operations” is not a useful project.
Neither is “automate procurement.”
A better scope has a trigger and a definition of done.
For example:
A supplier acknowledgement arrives, and the process ends when the PO is confirmed or a buyer receives a precise exception.
Or:
A technician closes a work order, and the process ends when the job is invoice-ready or the missing requirement is assigned for review.
Or:
A warranty repair order is complete, and the process ends when the OEM claim is submitted and eventually reconciled against reimbursement.
Those boundaries are small enough to build, test and measure.
They are also small enough to fail safely.
The workflow needs a state of its own
The core systems usually store records.
The missing layer stores process state.
That distinction matters.
A warranty system may need states such as:
- documentation incomplete;
- ready to submit;
- submitted;
- awaiting OEM response;
- rejected;
- resubmission required;
- approved;
- credit expected;
- reconciled.
The DMS may store the repair order.
The OEM portal may store the claim.
Accounting may store the receivable.
None of them necessarily owns the complete state above.
A small coordination system can own that state without pretending to become the new DMS, OEM portal or accounting package.
Routine cases and exception cases should look different
Many operational processes are repetitive because the normal cases are very similar.
That is good news.
Software can move the normal path quietly.
Humans can focus on the cases where:
- a value changed;
- an identifier cannot be matched;
- a required document is missing;
- a policy decision is needed;
- a system failed;
- the case falls outside known rules.
The important design principle is not “remove the human.”
It is:
do not require a human to re-check the cases the rules already understand.
That is the difference between useful automation and a brittle attempt at full autonomy.
Evidence should travel with the decision
A small operational system should be able to explain why it moved a record.
If it accepts a supplier acknowledgement, it should be possible to see:
- which PO was matched;
- which supplier response was captured;
- what date, quantity and price were found;
- which rules passed;
- what was written back.
If it flags a warranty claim, the user should see exactly which required evidence is missing.
If it blocks an invoice, the user should see which PO, receipt or service document does not reconcile.
This is especially important when the workflow begins with PDFs, emails or external portals.
Automation is easier to trust when it can show its work.
When a small operational system is a good fit
The pattern is strongest when several conditions appear together:
The work repeats often.
A process that happens twice a month may not deserve software.
The same systems appear every time.
The sources and destinations are reasonably stable.
The normal path is understandable.
People can explain what usually happens and what “done” means.
There are recurring exceptions.
Missing POs, changed dates, rejected claims, incomplete closeout packages and similar cases happen often enough to name.
The workflow is company-specific.
Generic software may cover 80% of the category while the final 20% still consumes real labor because of customer, vendor, industry or internal rules.
That last condition is important.
If the workflow is fully standardized and a mature SaaS product already solves it, buying that product is usually better than building.
When not to build anything
Sometimes the correct answer is configuration.
Sometimes it is process cleanup.
Sometimes it is better source data.
Sometimes it is simply keeping the spreadsheet.
Do not build a coordination layer because a workflow is annoying once.
Build when the same translation keeps happening, across the same systems, under stable rules, with enough volume that the manual coordination has become a permanent operating cost.
Three examples of the same pattern
The rest of this blog goes deeper into concrete workflows.
In warranty claims automation, the handoff is between repair orders, OEM requirements, parts returns and reimbursement.
In supplier PO acknowledgement automation, the handoff is between supplier responses and the open PO in the ERP.
In service work order automation, the handoff is between dispatch, parts, field completion and invoicing.
Different industries.
Different systems.
Same structural problem.
The systems of record already exist.
The repetitive work survives between them.