The Two Questions I Use to Decide What to Automate Next

When someone asks me what they should automate first, I do not give them a tool list. I ask two questions. I learned the first two questions from Nate Herk through AI Automation Society Plus and adapted them for my work. The exact lesson is in a member resource, so I cannot provide a public source for its wording. The third question and the checklist below are my adaptation.

The questions are simple. The answers usually surprise people.

Question one: What would break first if we doubled our leads?

This question works because it bypasses the productivity trap. The productivity trap is optimizing things that feel urgent but do not actually move revenue. You spend two weeks building an automated reporting dashboard while the real bottleneck is that your founder spends 20 hours a week on sales calls and cannot take more.

When you ask what breaks with double the leads, you get the capacity constraint. Not the thing that annoys you. The thing that physically cannot scale.

Consider a service business whose founder handles every onboarding call. If more leads arrive, onboarding may become the capacity limit before demand generation does. A scheduling link, a questionnaire, and a prep draft are candidate improvements. Measure the time saved and the client experience before claiming a revenue gain.

The framework forces you to map the chain. Lead comes in. Someone qualifies it. Someone does the first call. Someone sends the proposal. Someone onboards. Someone delivers. Someone follows up. One of those links is the weakest. That is your automation target. Everything else is noise.

Question two: What is the solo constraint?

This is the sharper knife. The solo constraint is the thing only you can do that is blocking everything else.

For most founders, the solo constraint is sales. Only they can close. Only they have the credibility, the relationships, or the domain knowledge. If closing takes 20 hours a week, that is 20 hours nothing else gets built.

The principle I took from the course is to move repeatable work away from the person who owns the scarce decision. It does not imply that the founder should work 40 hours on one task or that every other task can be automated. That sounds obvious until you try it. Most founders I talk to spend their best hours on things that could be done by a process, a template, or a capable person with a checklist. The solo constraint analysis makes that visible.

I have been applying this to myself since May. My solo constraint is not sales. It is the strategic decisions that determine which of the 50 things in my task list are worth doing. I can delegate research, writing drafts, building pipelines, and running audits. I cannot delegate "is this the right problem." So my automation work targets everything that feeds into that decision: data gathering, competitive analysis, performance reporting, surface-level research. I want those things done before I sit down to think, not during.

The third question I added

Nate's framework covers the business layer. But I run AI agents that operate autonomously, and I noticed a gap. You can identify the bottleneck and still automate the wrong thing because the process is not ready for an agent.

I added a third question: "Is this process deterministic enough for an agent to run reliably?"

Deterministic does not mean simple. It means the inputs are stable, the rules are explicit, and the failure modes are predictable. A process where the answer is "it depends, let me check three things and decide" is not deterministic. A process where the answer is "follow this checklist, if X then Y, and flag for review if Z" is.

For a content calendar, topic selection may involve customer questions, competitor activity, and the product roadmap. An agent can gather candidate topics with source links while a person chooses and refines them. Compare the total research and review time with the prior process, and inspect whether the chosen topics served customers.

This is the pattern I keep using. Agents are best at the work that happens before and after the human decision. Surface the options. Draft the output. Check for errors. Flag anomalies. Do not try to replace the decision itself until the rules are explicit enough to code.

The framework as a checklist

Here is the adapted version I use when evaluating any automation opportunity, whether for myself or for a client business:

1. Map the revenue chain. Write down every step from lead to cash. Be specific. Not "sales" but "discovery call, proposal, follow-up, close call, contract, payment, onboarding."

2. Find the capacity constraint. Which step would break first under 2x volume? Not which step is annoying. Which step physically cannot handle more.

3. Find the solo constraint. Which step only the founder or a specific person can do? What is blocking because it is waiting on one person?

4. Score the automation surface. For each candidate step, ask:

   • Are the inputs stable and predictable?
   • Are the rules explicit enough to write down in a checklist?
   • Are the failure modes known and detectable?
   • Can a human review the agent's output quickly if needed? The questions are prompts for discussion, not a validated scoring model.

5. Build the automation layer that feeds the constraint, not the constraint itself. If the solo constraint is strategic decision-making, automate the research and reporting that feeds it. If the solo constraint is sales, automate the prospecting, scheduling, and follow-up so more time goes to actual conversations.

6. Verify with a number. After automation, measure the hours recovered for the constrained person. If the time recovered is small, check whether quality or customer experience improved before deciding whether to keep the automation.

What this framework misses

The Income Lens assumes the bottleneck is internal capacity. That is true for most small and mid-size businesses, but it misses market-side constraints. If demand is the problem, doubling leads is not a capacity question. It is a product-market fit question. No amount of automation helps if nobody wants the thing.

It also assumes the business knows its revenue chain. Some businesses need to map the process before choosing a tool. Keep as many steps as it takes to represent the real work. Automating a process you do not understand produces an automated mess instead of a manual mess.

The solo constraint question has a blind spot too. Founders tend to overstate what only they can do. I have caught myself doing this. "Only I can write the proposal" is often "I have not trained anyone else to write the proposal." The solo constraint should survive a challenge. If you can train someone else to do it reliably, the issue may be a training gap rather than a permanent founder-only task.

I use this framework every time I sit down with a business that wants to add AI agents to their operation. The tooling question comes first because tools are visible and frameworks are invisible. But the answer to "what tool should I use" is always downstream of "where is the actual bottleneck." Skip the first hour of tool demos. Ask the two questions. Then build.

Use the free Decision Packet Writer to record the constraint, alternatives, evidence, and next test.