Summary: A practical prioritisation framework for choosing automation projects that improve speed, visibility and control without automating a broken process.
Automation succeeds when it starts with an operational problem, not with a tool. A business can buy an excellent CRM, workflow engine or AI assistant and still get disappointing results if the underlying process is unclear, ownership is weak or exceptions are not defined.
For Nigerian organisations, the best first automation project is usually not the largest process. It is the process where repetitive work, delay and lack of visibility create a measurable cost.
Start with the process, not the software
Before choosing technology, write down how the work moves today. Identify the trigger, the people involved, the information required, the decisions made, the handoffs, the exceptions and the final output.
A useful process map can be simple. For example, a customer enquiry may arrive through a web form, email, phone call or WhatsApp. Someone records it, assigns it, follows up, prepares a quotation and waits for a decision. The automation opportunity is not simply "install a CRM." It is to remove missed enquiries, repeated data entry, unclear ownership and forgotten follow-up.
The same principle applies to purchase requests, document approvals, school admissions, service tickets, invoice reconciliation and management reporting.
Rank automation candidates using five tests
A practical prioritisation model is to score each process from one to five on five dimensions.
Frequency. How often does the process happen? A small inefficiency repeated hundreds of times each month can be more valuable to fix than a large process that happens twice a year.
Delay. How much waiting occurs between steps? Look for approvals sitting in inboxes, documents moving physically, or decisions waiting for information that already exists elsewhere.
Repetition. How much work is copied or re-entered? Re-keying customer details, copying figures between spreadsheets and preparing the same report manually are strong candidates.
Visibility. Can management see the current status without calling people or opening multiple files? Poor visibility often creates hidden work and weak accountability.
Risk. What happens when a step is missed? Processes involving money, customer commitments, access rights, compliance records or safety deserve particular attention.
The strongest first projects usually score well in several categories at once.
Automate the stable path and design for exceptions
A common mistake is to automate only the ideal path. Real operations have exceptions: a document is incomplete, a payment cannot be matched, an approver is unavailable, a customer changes a request, or a record fails validation.
Good workflow design defines the normal path and the exception path. The system should know when to proceed automatically, when to request more information and when to escalate to a person.
Human judgement should remain where context matters. Automation should remove repetitive coordination work, not force every situation into a rigid sequence.
Choose a first project that can prove value
The first automation project should create visible evidence. Useful measures include response time, turnaround time, percentage of tasks completed within target, number of overdue items, error rate, unmatched transactions, duplicate data entry and time spent producing reports.
Baseline the current performance before implementation. Otherwise, it becomes difficult to show whether the new system improved anything.
A well-chosen first project also creates reusable building blocks: identity and access controls, notification services, approval logic, dashboards, integration patterns and audit trails. Those components can support later workflows.
Avoid automating a bad process unchanged
If a process contains unnecessary approvals, duplicated forms or unclear responsibility, digitising it can make the inefficiency faster rather than better.
Before implementation, ask:
- Which steps are required by policy or regulation?
- Which steps exist only because the old system could not do something?
- Can data be captured once and reused?
- Can approval limits be simplified?
- Which reports are actually used?
- Which exceptions require human judgement?
- Who owns the process after go-live?
This short design exercise can remove more waste than the software itself.
Think in layers
A durable automation architecture usually has several layers: input, rules, integration, action and control.
Inputs may come from forms, email, mobile apps, databases or existing systems. Rules validate the data and decide what happens next. Integrations move information between systems. Actions create tasks, alerts or transactions. Control is provided by dashboards, audit logs and exception reporting.
This layered model makes it easier to change one component without rebuilding the entire operation.
A practical first-90-day approach
In the first month, map two or three candidate processes and establish baseline measures. In the second month, implement one tightly scoped workflow with clear ownership and exception handling. In the third month, measure results, correct friction points and decide which reusable components should support the next process.
The objective is not to automate everything quickly. It is to create a repeatable operating model for improvement.
Questions to answer before approving the first automation
- What event starts the process and what proves it is complete?
- Who owns the process after go-live?
- Which steps consume the most waiting time?
- Which data is being captured more than once?
- Which exceptions occur often enough to deserve a defined route?
- Which baseline measure will prove whether the change helped?
What good looks like
A successful first automation is understandable without the implementation team standing beside it. Staff know where work enters, managers can see status, exceptions have owners, and the organisation can compare the new performance with the old baseline. It should also leave behind reusable foundations for the next workflow rather than creating another isolated application.
REVTEK perspective
REVTEK's process-first principle is simple: connect what already works, replace only what must change, and build control into the workflow. The best automation project is the one that makes a real operating problem easier to see, manage and improve.