The next AI shift for small business is not a smarter chatbot

TL;DR

Writer, an enterprise AI vendor, launched a feature this month called Skills: automations that fire when a real business event happens, not when someone remembers to open a tool and type a prompt. Salesforce reports similar event-driven agent use crossing 3 billion automated workflows a month. The pattern is becoming ordinary, not experimental. For a small business, the useful version of this is not the enterprise platform. It is the same idea, built with tools you likely already have: pick one recurring event, define exactly what should happen when it fires, and check the results for a few weeks before trusting it to run unwatched.

What did Writer actually launch?

Writer launched a feature called Skills: reusable building blocks that encode how your team is supposed to handle a task, paired with triggers tied to real business events (source). Instead of an employee opening a chat window and describing what they need, the automation runs when the event it is watching for actually occurs.

Writer is positioning this against Amazon, Microsoft, and Salesforce, all building toward the same idea from different starting points. Salesforce's own numbers back up how ordinary this pattern has already become: its Agentforce product is now used by 18,500 enterprise customers, running more than 3 billion automated workflows a month (source).

Why does the trigger matter more than the model?

Because the trigger is what decides whether the automation actually gets used. A powerful AI tool that requires someone to remember it exists, open it, and describe the task well, competes with every other task on that person's plate. Most days, it loses.

An automation tied to an event does not need to be remembered. A new form submission, a support ticket, an order crossing a threshold, these already happen whether or not anyone is thinking about AI that day. The task simply runs when the event does.

This is not a new AI capability so much as a new default. The AI work most SMB owners have already tried, drafting an email, summarizing a document, still requires a person to start it. Tying that same work to an event most owners have already automated away, at least in intent.

It is worth being honest about what changed and what did not. The underlying AI models doing the drafting or summarizing are not meaningfully different from what a small business could already access a year ago. What changed is the plumbing around them: a defined trigger, a defined task, and a way to route the result. That plumbing was always the harder, less glamorous half of making AI useful, and it is the half most vendor marketing skips past.

Where does this actually fit in a small business, without an enterprise platform?

You do not need Writer's product, or Salesforce's, to use the underlying idea. Most small businesses already have the pieces: email rules, form-to-spreadsheet automations, scheduling tools, a CRM with basic triggers. The pattern that matters is trigger, task, check, not the specific vendor.

Concretely: a new customer inquiry form submission triggers a first-draft reply for a person to review before sending. A support ticket tagged "billing" triggers a draft response referencing the actual invoice. A weekly sales export triggers a short written summary instead of a blank spreadsheet someone has to interpret cold.

None of those need a data team. They need someone to name the event precisely, write down what a good automated response looks like, and check the output closely for the first few weeks, the same discipline that makes any AI automation trustworthy, just applied at the moment the event happens instead of whenever someone remembers to run it.

I have walked owners through this exact naming exercise more than once, and the part that trips people up is not the automation itself. It is being precise about the event. "When a customer reaches out" is not an event a tool can act on cleanly. "When a form is submitted on the contact page" is. The vague version feels more natural to describe out loud. The specific version is the one that actually works, because a system can only trigger on something it can detect.

What goes wrong if a business skips the check step?

The same thing that goes wrong with any AI automation nobody is watching: it runs consistently, including on the exceptions that were never part of the pattern.

An event trigger removes the moment where a person decides whether now is the right time to run the task. That is the whole point, and it is also the risk. A trigger that fires on every new order works fine until an order is unusually large, unusually urgent, or from a customer with a complicated history, the ten percent of cases where a person's judgment mattered.

The fix is not avoiding triggers. It is defining, up front, which events are safe to fully automate and which ones should trigger a draft for a human to approve instead of an action that goes straight out. That single distinction is most of what separates a useful automation from an embarrassing one.

A simple version of this split works for almost any first automation: routine, low-stakes events run straight through. Anything touching money above a small threshold, anything from a customer flagged as high-value or already upset, or anything the automation was not explicitly built to handle, routes to a draft a person approves instead. You do not need to predict every exception in advance. You need the automation to recognize when it has left the pattern it was built for, and hand off instead of guessing.

Skipping that step is how a reasonable-sounding automation turns into a story you tell apologetically. A reply that goes out to every new order works fine until an order arrives from a customer mid-dispute over a prior shipment, and the automated reply cheerfully confirms a new charge without any awareness of the history. Nothing about that failure requires a bug. The automation did exactly what it was built to do. It just was not built to notice that this particular event was not like the others.

The businesses that avoid this are not the ones who wrote more rules trying to anticipate every case. They are the ones who kept the threshold for "hand this to a person instead" wide enough in the first month, watched what actually came through it, and only narrowed that threshold once the pattern of real exceptions became clear from watching, not guessing.

So what does this mean for your business?

The time case is direct: every task currently waiting on someone to remember to start it is a task with hidden delay built in, measured in hours between when the event happened and when a person got around to it. Moving that task to a trigger removes the delay, not just the labor.

The money case follows from response speed specifically. A first-draft reply that goes out within minutes of a support ticket or a sales inquiry, instead of hours later, tends to land while the customer is still paying attention, still deciding, still willing to give you the benefit of the doubt. That is the same logic driving enterprise vendors to race toward this pattern, not a guaranteed outcome for every business, but a reasonable bet on how people actually behave when a response either shows up promptly or does not.

The growth case is capacity. A task that used to require someone remembering to check a queue now runs on its own, freeing that person's attention for the exceptions and the judgment calls a trigger should never fully own. If you want a structured way to find which recurring event in your business is worth automating first, that is exactly the exercise in Arios's piece on the seven most automatable processes in every company, paired with the same review discipline covered in where AI delivers the fastest wins in operations.

Pick one event your business already generates every week. Define what a good automated response looks like. Watch it closely for a month before you trust it to run unwatched. That is the entire shift, at small business scale.