Start with the journey of a real request
To design a process automation, follow a request from arrival to completion. Record who receives information, where they store it, which decisions they make and what they pass to the next person. That journey reveals repeated work, interruptions and dependencies that a list of tools alone rarely makes visible enough to address.
Imagine a business receiving quotation requests through its website. Someone reads the form, copies the contact into a spreadsheet, alerts a colleague and checks availability for a meeting. If information is missing, a message exchange begins. This example contains several tasks, alongside decisions about priority and responsibility.
I would start by asking where follow-up gets lost. Are requests forgotten? Do two colleagues contact the same person? Is information missing when the meeting starts? The answer helps choose the first change. Automating data copying can save effort without resolving the forgotten requests that are damaging sales.
In Sextas Ímpares #142, about analysing advertising with AI, I explained a sequence connecting campaign data, a spreadsheet, an automation and information sent through WhatsApp. The connections between stages are an important part of the example. Its value depends on information reaching the decision-maker with enough context. The class is in Portuguese.
Separate rules from tasks that require interpretation
A rule handles behaviour you can define in advance, such as checking a field or routing a request by service. AI can help when text needs interpretation or context needs summarising. Design this division before choosing tools, so each stage has a clear responsibility and can be tested against an expected result.
In the quotation example, a rule checks whether contact details exist and whether the request has already been recorded. A model can suggest the requested service from the description. If the message mentions two services, the system should preserve that ambiguity and allow review. Inventing certainty to keep the workflow moving creates problems later.
In class #151, about advertising management in the AI era, I showed a tool built with AI assistance that executes defined rules. This distinction helps when assessing proposals: using AI to build a system does not require calling a model during every execution.
When decisions are open-ended and several tools are available, another discussion becomes relevant: AI agents for businesses. Before reaching that point, I want to understand how much of the process can be made explicit. Teams can check results more effectively when they know what each step was supposed to do.
Define states that show what actually happened
An automated process needs to distinguish information received, work in progress, completed actions and situations requiring intervention. Those states should correspond to verifiable events. Sending a notification does not prove someone answered the customer, and attempting an integration does not prove the record was saved successfully in the destination tool.
Consider the states of a request: received, incomplete, assigned, contacted and completed. Each change needs a reason. Assigning a salesperson might happen automatically; marking contact as completed should depend on a recorded interaction. If everything moves straight to completed, you lose the ability to see where work is stuck.
It also matters to distinguish failure from uncertainty. A platform may stop responding after receiving an operation. Repeating it blindly can create duplicates. The design should explain how to confirm the outcome before trying again, particularly when actions involve messages, documents or changes that other people will use.
This applies to sales automation with AI, but also to reporting, internal requests and content production. Work status must remain understandable when the usual person responsible is absent. If only one person can interpret the records, the dependency remains even after the manual task has disappeared.
Test exceptions before increasing volume
Testing an automation requires incomplete inputs, repetitions and unavailable tools, alongside the case where everything works. Define the expected result for each situation and verify that someone can correct the problem. Confidence to increase volume should come from observing those cases, using examples representative of the work the team actually handles.
I would prepare a small collection of fictional requests: a normal one, another missing essential information, a duplicate and one mixing different subjects. I would add a test with the integration disconnected. The aim is to see whether the workflow preserves information, provides a useful alert and can resume without starting everything again.
The people using the process should participate in this review. A developer can verify that a message was sent; a salesperson recognises that the reason for contact is missing. An operations colleague may notice that a field means something different in daily work. These contributions change the design before the automation spreads.
Keep the example that failed and the corrected behaviour. Run that case again during the next change. Learning then stays with the project and supports maintenance. The page on security for AI-built applications develops related considerations, including access, data protection and validation across the application.
Measure time, quality and recovery capability
Evaluating an automation should include time saved, review effort, delivery quality and the ability to recover from failures. Compare similar situations before and after the change. A faster process can still be expensive if it needs frequent corrections or leaves all maintenance concentrated in one person who becomes difficult to replace.
If a team stops copying data, observe what happens to that time. People may respond sooner, support existing requests better or reduce accumulated work. Connect measurement to one of those consequences. Counting automated operations alone says little about the improvement the business experiences in its actual delivery.
I would also measure unassigned requests, duplicates and time to resolve a failure. These signals help distinguish an automation that organises work from one that simply executes quickly. The article on growth, margins, teams and AI develops this connection between operational capacity and business decisions.
Choose an observation period that includes ordinary days and some exceptions. If the trial only covers straightforward requests, say so in the assessment. That honesty makes it possible to decide what is ready to expand and what needs further review, without treating a favourable demonstration as a guarantee for the whole operation.
Prepare maintenance and choose suitable support
Maintenance needs an owner, sufficient documentation and a clear way to monitor errors. Before handing the process to the team, confirm who controls accounts, access and changes. If you want implementation support, SpartAds is the route for discussing the work; if you want to develop skills, start with training and mentoring.
In my 2022 book, I advocated documenting processes and lessons to make delegation easier. Today I would add example inputs, routing decisions and criteria for reviewing AI output. Someone joining the project should understand what happens, what they can change and when they need help from another person.
Avoid starting by replacing every tool. Bring one process, its observed problems and its current limitations to the discussion. The AI consulting for businesses page explains how to prepare that assessment. The scope should follow the need, the integrations and the ability to maintain the solution over time.
To discuss implementation, present the context to SpartAds for AI and automation services. To discuss decisions while building your own project, explore AI and business mentoring. In either case, start with the work you want to improve and what you have already observed.