The mistake of starting with the tool instead of observing the operation
Starting with the tool almost always produces useless automations, because you try to fit your work into a piece of software instead of solving a concrete problem. In the class I gave, I said this directly: "First you're going to map out what the needs are, what you want to automate. The tool comes after."
It's common to ask which bot is best or which language model is trending. But technology is the simplest part of the process. What separates people who extract value from AI from those who just have fun with it is the observation work that comes before: noticing where the team loses time, where decisions repeat, and where the incoming data is weak.
If you don't know where the friction points in your operation are, you end up automating steps that bring no return at all. It's worth spending a week or two simply watching the daily routine carefully and writing down what repeats.
The four inventories: tasks, decisions, time, and unmet needs
In the class, I proposed four inventories any business can build without relying on any tool: repetitive tasks, recurring decisions, time invested per team member split between high- and low-impact work, and unfulfilled needs. The first pillar is repetitive tasks: mechanical actions like entering leads into a CRM, answering transactional emails, or publishing content.
The second is recurring decisions, such as deciding whether a contact should move to a sales call, and the variables that decision requires. The third is time invested per team member, separating what generates real impact from what merely consumes hours. The fourth pillar, unfulfilled needs, gathers the work you know you should be doing but that keeps slipping because the team is buried in operational tasks.
I gave a simple example of this last point in class: regularly posting reels on Instagram is something many people know they should do but never find time for. Delegating that production to an automated flow, even if the result isn't identical to what you'd do yourself, is still better than posting nothing.
How to use AI in business beyond chatbot prompts
How to plan an app with Claude Code before you start coding
Mapping task, frequency, owner, and time
For the inventory to be useful, each task needs a defined frequency, an owner, and an honest measurement of average time spent. That quantification is what turns vague complaints about lack of time into something you can actually decide on with data.
You can open a simple sheet with columns for the task, frequency, who does it, and average duration. In class I used the example of a salesperson spending thirty minutes researching, qualifying, and drafting the first message for each lead: with twenty leads a week, that's ten weekly hours just on preparation work.
Once the table is filled in, the pattern becomes obvious without needing intuition: you can see which team is operating at its limit without that effort translating into visible client value.
Why inputs and errors decide whether the automation works
No automation works well without consistent inputs and clear rules for handling errors and exceptions. I was blunt about this in class: "Data is gold. If I don't have good data, good context, artificial intelligence becomes stupid." When mapping each task, it's worth noting what data is actually needed.
If your website form only asks for a name and email, there is not enough context for any automation to evaluate the contact's relevance. I used this gap as an example to explain how AI can retrieve public company data missing from the form.
Feeding an automated flow with inconsistent information forces the system to guess instead of follow a rule. That's why it's worth checking, before automating, how often the team currently corrects these gaps by hand.
Working through the cost-per-decision calculation
In Sextas Ímpares #128, I presented a formula to compare manual work cost against the cost after introducing automation and AI: cost per decision equals human time times hourly rate, plus infrastructure cost, all multiplied by the error rate and the latency rate.
In the class example, the salesperson spends 30 minutes (0.5 hours) per lead, at an hourly cost of 25€, an infrastructure cost of 1€, a 20% error rate, and a 20% latency rate. The math: (0.5 × 25€) + 1€ = 13.50€; then 13.50€ × 1.20 × 1.20 = 19.44€. That's the exact figure I presented: "That gives a cost per decision for each lead reaching my company of 19.44."
After introducing automation and AI to gather context and prepare a draft response for human review, time drops to 6 minutes (0.1 hours), error falls to 5%, and latency to 3%. The math becomes: (0.1 × 25€) + 1€ = 3.50€; then 3.50€ × 1.05 × 1.03 ≈ 3.79€. The saving per decision is 15.65€, which in class I extended to a hypothetical operation handling 500 monthly leads, reaching roughly 7,825€ in monthly savings on that single process, before other costs of the business.
The formula percentages (20% error, 20% latency) served as an illustrative exercise that I explicitly presented as adjustable. Each business should use its own figures, as these specific numbers illustrate the model rather than prove statistically that your savings will match this outcome.
What to do with the time automation frees up
An automation isn't only about cutting direct cost; it's also about freeing time for the higher-value work that currently gets left behind. That's where the unfulfilled needs inventory comes in, holding everything we know we should do but never find time for.
If the first automation recovers weekly hours for the team, that time can be redirected toward what was sitting on the unfulfilled needs list, instead of simply being absorbed by more operational tasks. Even when the freed hours are modest, it's worth deciding deliberately where they go, since small blocks of time can also create value if pointed somewhere useful. That shift, from reactive to proactive, is what I described in class as the real gain: not just spending less, but doing more business by responding faster and with better quality.
Simple criteria for choosing your first automation
For a first automation, I would start with a daily-frequency task, with relatively structured inputs, and with a human reviewing before final dispatch. I described this model in class with the lead-qualification example: automation gathers context, AI drafts a response, and the person only has to review, adjust if needed, and send.
The most common mistake is trying to automate your company's most critical and riskiest process right away. It's worth first building confidence with a task where the system acts as an assistant, not an autonomous decision-maker, and only later, once the operation is stable, moving to higher-risk processes.
Once a first win is tested and stable, the team gains confidence to keep going. That's how adopting artificial intelligence stops being a scary project and becomes a regular habit for improving margin.
Sextas Ímpares #128: the class this reasoning comes from
This reasoning comes from the talk I gave on the first day of Ad Summit, later made available as Sextas Ímpares #128. You can watch the full recording at https://www.youtube.com/watch?v=XTWg_GjK35Q. It's worth watching from around 41:40, where I talk about mapping needs before the tool, and from around 45:41, where I present the task and decision inventory.