Seven Days to Know if AI Belongs in Your Business

Small business AI adoption has grown sharply since 2019. The firms doing it are mostly using AI for basic tasks and not advancing further. That pattern is not explained by cost or technical access — both have dropped steadily. The Federal Reserve Bank of San Francisco's research on small business AI adoption identifies the binding constraints as skills, trust, and time. None of those are solved by reading another article about AI strategy.

The thing planning cannot do

Abstract strategy work stalls without concrete experience. This is not a preference — it is what the research documents as the mechanism behind shallow adoption. Founders who have spent time evaluating AI without deploying it do not emerge with more trust in the tools. They emerge with more questions and the same unresolved concerns about accuracy, privacy, and whether the output is good enough to act on.

A scoped experiment changes what questions you are asking. When you run an automation on a real task inside your own business, the accuracy question becomes specific: does this draft email require editing before I send it, and how long does that take? The privacy question becomes specific: what data did I feed into Make.com or Zapier, and where does it go? Abstract planning keeps both questions theoretical.

No-code platforms like Make.com and Zapier have case studies showing that narrow automations produce visible, staff-observable relief with modest setup effort and no custom code. Automating email responses, data entry, or content routing — these are not transformations. They are one task, working differently, in a way your team notices within days.

Pick the task before you pick the tool

The sprint starts with task selection, not tool selection. The right task for a first sprint has three properties: it happens at least a few times per week, it follows a predictable pattern, and a mistake in the output is recoverable before it causes damage. Drafting a first-pass response to a common customer inquiry fits. Updating a spreadsheet with data from a form submission fits. Automatically sending a contract for review when a deal reaches a certain stage fits.

Pick the task first. Then open Make.com or Zapier and search for a template that matches it. Both platforms have pre-built automation templates that require configuration, not coding. Day one is task selection. Days two and three are setup and testing on non-live data.

A working automation is not the same as a useful one

This is where the strategy-first critics have a point worth taking seriously. A founder who finishes the sprint with a working email-draft automation has learned that the tool functions on that task. They have not learned whether the outputs are accurate enough to trust at volume, whether the data fed into the tool is handled safely, or whether the staff member running the automation next month will keep using it.

The research addresses this directly: constrained experiments surface practical questions more effectively than planning does, provided ethical and security guardrails are built into the sprint design. That condition matters. A sprint designed as a pure speed exercise — build fast, check nothing — reproduces the same shallow adoption it was meant to break. The guardrails are not optional additions to the sprint. They are what make the sprint's evidence usable.

Days four and five of the sprint should include a deliberate review: read every output the automation produced. Flag the ones you would not have sent or used without editing. Count them. That number is your accuracy baseline. It is also the first piece of concrete operational evidence you have, and no planning exercise produces it.

Day six, ask the staff member who will own this automation whether they trust it enough to run it without your supervision. Their answer tells you more about organizational readiness than any readiness assessment framework.

What you have at the end of seven days

On day seven, you have one automation running on one task, an accuracy baseline from real outputs, a privacy question you have either answered or now know you need to answer, and a staff member whose trust level you have actually measured.

That is not a transformation. It is four pieces of evidence you did not have before. The firms stuck in shallow adoption since 2019 are not stuck because they lack ambition. They are stuck because they have no structured mechanism for converting a first experiment into the operational knowledge required to go deeper. The sprint is that mechanism, and the evidence it produces is what the next decision gets built on.