A team may spend hours moving enquiries between systems, checking documents or preparing the same reports each week. A business case that skips measurement usually overstates savings and understates review work. This article outlines a practical sequence that keeps financial language honest.
Document one workflow in enough detail to test it
Choose a process with a recognisable beginning and end. Record the trigger, input data, systems involved, decision points, outputs and owner. Follow a real example from receipt to completion. If the process depends on informal judgments or information stored in an employee's memory, document those dependencies before attempting to automate them.
The objective is not to produce a lengthy requirements document immediately. It is to establish whether the work is repeatable, whether source information is reliable and whether the business can define a successful outcome. Scoring guidance is in How to Identify Processes Worth Automating.
Establish a measured baseline
Count how often the process occurs and how long a typical instance takes. Record exceptions separately. The average may conceal important differences: an ordinary enquiry could be handled in a few minutes, while an incomplete or disputed request may require substantial follow-up. Record the proportion of tasks requiring escalation, the delay between handoffs and the frequency of repeated data entry.
A useful baseline includes both quantity and quality. Processing time is important, but so are missed requests, duplicate records, delayed approvals and the ability to recover from failure.
Estimate the addressable workload
Not every minute in a workflow is removable. A review step may exist because a business needs professional judgment or formal authorisation. For each stage, classify the work as suitable for deterministic rules, AI-assisted preparation, human approval or full manual handling. Estimate potential savings only for stages that the business can genuinely change.
Where AI-assisted classification is proposed, consider what happens when the result is uncertain. If a large share of cases requires correction, the business case may still be positive, but the review workload must be included rather than ignored. See Human Approval in AI Workflows and Custom AI Agents vs Traditional Automation.
Include the real integration and operating costs
A project budget should cover discovery, implementation, integration, testing, documentation and any new access or infrastructure required. Ongoing costs may include workflow hosting, paid application plans, model usage, monitoring and corrective maintenance. If a critical application is unsupported or restricts automated access, the proposed integration may need to change.
Request a quote that distinguishes one-time work from recurring commitments. Check whether the customer can operate the solution independently and what responsibilities remain with the supplier after handover. Miguelito AI publishes starting prices and discovery terms on the Pricing page; use those as budget anchors, not as forecasts of total project cost. For cost components, see AI Automation Costs for Small Businesses.
Define acceptance criteria before development
An acceptance criterion should describe observable behaviour. For example: every valid submitted enquiry creates a traceable record; missing required fields are sent to a review queue; duplicate submissions do not create duplicate customer records; staff can see when an integration fails; outbound customer messages require approval where specified.
Avoid vague commitments such as "smarter operations" or "dramatically improved productivity." The project should be judged against agreed behaviour and measurable process outcomes.
Start with a controlled implementation
An initial rollout should be narrow enough for the business to review outputs and correct the process if necessary. Use realistic test data and agreed permissions. Compare actual handling times and exceptions with the original baseline, and document issues before expanding to additional teams or applications.
A successful first implementation creates a maintainable workflow and establishes how the organisation will evaluate future opportunities. It need not automate an entire department to be commercially useful. Plan for interruptions with failure handling guidance.
Choosing the next step
If the primary problem is unclear requirements, begin with process discovery. If data already moves between supported systems but employees repeatedly copy it, consider integration and rule-based automation. If staff must interpret variable text or documents, investigate whether an AI-assisted stage can prepare useful information for review. Bespoke software becomes appropriate when the business needs interfaces, data structures or permissions that existing products cannot provide.
Miguelito AI uses this process-led approach to scope automation work through Business Process Automation and Custom AI Agents. A short introductory conversation establishes suitability; a paid assessment may be appropriate when detailed technical planning is needed. The development proposal then defines what will be built, how it will be tested and who is responsible for ongoing operation.
If you want help turning a baseline into a scoped proposal, request a business consultation.