What Should You Hand to AI? Building Your First AI-Enabled Business Workflow

Not everything belongs in AI's hands, and that is the whole point of choosing well

A content marketer at a twelve-person company gets told, in a Monday stand-up, to “start using AI more.” No specifics, no examples, just a general sense that everyone else is doing it and the team should catch up. She picks the task sitting at the top of her list: the client-facing update email that goes out every Friday, the one where tone matters because it’s the client’s only regular touchpoint with the account that week. She feeds it a rough outline, gets back something confident and wrong about a deliverable date, catches it before it sends, and quietly decides AI isn’t ready for her work yet.

The tool wasn’t the problem. The task was. A client-facing email with a wrong date in it is exactly the kind of task where a first mistake costs something real, and it’s also ambiguous enough that “good” is hard to pin down in advance. Real consequence plus fuzzy standards is close to the worst place to start.

Most advice on adopting AI treats this stage as a formality: pick something, anything, and get going. That’s backwards. The task you hand off first sets the tone for how much your team trusts AI with the second one, and the third. Get it wrong and you spend the next quarter undoing the skepticism instead of building on momentum.

So before criteria, before mapping, before any of it: some tasks should stay off the list entirely, for now, and it’s worth naming which ones plainly.

• Anything customer-facing where a wrong answer damages a relationship you can’t easily repair, like the client update above, or a first response to an already-frustrated customer.
• Anything touching someone’s pay, benefits, or employment status. The consequence of a mistake isn’t recoverable the way a typo is.
• Anything with real legal or compliance exposure, where “mostly right” isn’t a defensible standard for what went out.
• One-off strategic judgment calls, like which vendor to choose or whether to enter a new market. These need a person weighing trade-offs that don’t repeat often enough for AI, or anyone, to get calibrated on them.

None of that means these tasks never touch AI at all. A first draft, a summary of options, a second pair of eyes, all fine. It means they’re not where you learn what your team is actually good at, or how much oversight a first workflow genuinely needs, before the stakes go up. That’s a question for later, once you’ve built the habit of checking on something lower-stakes first.

The criteria for a good first workflow to hand off

Once the obviously wrong candidates are off the table, the actual decision comes down to four things, and they matter more than how exciting the task sounds or how much time it currently eats.

High repetition. You do this same task, roughly the same way, at least weekly. A one-off project, however painful, doesn’t give AI, or you, enough repetitions to get calibrated. Part of the value of a first workflow comes from watching it run many times, not once brilliantly.

Clear inputs and outputs. You could describe, in a sentence, what goes in and what a good result looks like coming out. If two competent people on your team would disagree about what “done well” means here, it isn’t ready yet. Ambiguity is what turns a five-minute review into a twenty-minute argument about whether the AI actually got it right.

Low consequence if it’s wrong the first few times. Not zero consequence. Low. A weekly internal report with a wrong number in it gets caught and corrected before anyone acts on it. A client-facing commitment with a wrong number in it doesn’t have that same margin.

A real, current bottleneck. This is the one people skip, and it’s the reason so many first workflows quietly die within a month. If the task isn’t actually costing anyone meaningful time or attention right now, there’s no one motivated to keep checking the output, refining the instructions, or noticing when it drifts. A workflow nobody needs gets abandoned before it’s had a fair test.

Run a few real candidates through it and the picture gets clearer fast.

The weekly reporting summary comes out on top here, and for good reason: it’s the shape of task almost every team has some version of. It’s also the example this piece follows through end to end, from what it actually looks like today to what it looks like a month after AI gets involved.

Mapping the workflow before you automate any of it

Before opening any AI tool, write down five things about how the task actually runs today. Not how you wish it ran, or how the process document says it runs. How it actually runs, including the part where you copy last week’s version and change the numbers because you’re behind on Thursday.

This step gets skipped constantly, because it feels like busywork when you could just start prompting. Skipping it is exactly why so many first workflows produce a decent-looking draft that still has to be quietly rebuilt by hand every week, because nobody wrote down what the task actually needed before asking AI to do it.

• The trigger. What starts the task? A calendar reminder, a Slack ping, the simple fact that it’s Friday.
• The inputs. Where does the raw information actually live? Which dashboards, which spreadsheets, which inboxes.
• The steps, in the order you actually do them. Not the order in a process document nobody follows.
• The judgment calls. Where do you currently decide something rather than just transcribe it? That’s usually the part worth keeping human the longest.
• The output. What does “sent” or “done” actually look like, and who receives it?

Mapped out plainly, for a marketing team’s Friday update, it looks like this.

The mapping step does one thing a lot of teams skip past: it shows you exactly which part is genuinely repetitive and mechanical, pulling four numbers into a template, and which part is a judgment call wearing a formality’s clothes. Those two things get built differently. The mechanical part is what you hand to AI outright. The judgment part is what stays with a person, at least at first, which is exactly what building the workflow actually means.

Building it step by step, with a human checkpoint built in

With the task mapped, building it is less about the tool and more about translating four of those five rows into instructions, and being honest about the fifth.

Turn the inputs and steps into the goal. Not “write the Friday update.” Something closer to: “Pull this week’s four core numbers from the campaign dashboard and CRM export I paste in, compare each to last week’s figures, and draft two or three sentences of context for anything that moved more than 10%, in the same structure as the last four weeks’ emails.” Specific enough that you, or anyone else, could look at what came back and say whether it actually did the job.

Decide what it drafts and what it never touches. For the reporting example, AI drafts the numbers pull and the context sentences. It doesn’t decide the framing for a genuinely bad number, the kind that needs a heads-up conversation before it shows up in writing anywhere. That’s not a technical limitation. It’s a choice about where judgment stays, made on paper before the first run, not discovered halfway through one.

Name the checkpoint. Not “someone will review it.” An actual person, at an actual moment. For a five-person marketing team, that’s usually whoever currently owns the Friday email, reading the draft before it sends, every single week, for at least the first month. Not spot-checking. Every one. Who that person is changes with the workflow: for anything financial, it’s usually whoever already signs off on the numbers; for a customer-facing draft, it’s whoever owns that relationship. Not a generic “the manager.” Microsoft’s own guidance for building agents that take real action makes the same point plainly: for anything with real stakes, the agent should be configured to ask for confirmation before acting, keeping ultimate control with a person.^[1]

Here’s a version of the mistake that’s easy to make. An operations coordinator sets up an intake-triage workflow for incoming support requests, tells it to “flag anything that looks urgent,” and calls the checkpoint done. Three weeks in, she notices the definition of “urgent” the tool settled on and the one her team actually uses have quietly drifted apart. It isn’t flagging billing disputes, which her team treats as urgent. It is flagging routine password resets, which nobody considers urgent at all. Nobody had written down what “urgent” meant clearly enough for either side to check against, so the drift went unnoticed until a customer complained about a slow billing response. The fix wasn’t more oversight. It was going back and writing the actual definition down, the same mapping step from the section before this one, which she’d skipped because the task felt too simple to bother with.

What to watch for in the first month, before you hand off a second workflow

A month in, the easy thing to check is whether the workflow ran. That’s the least useful of the three questions worth asking, and it’s the one most teams stop at.

Use. Did it actually run, on schedule, without someone quietly reverting to the old manual way because it felt faster that particular week? For the reporting example, that’s a simple yes or no across four Fridays.

Persistence. Is it still running a month in, without you reminding anyone it exists? A workflow that needed three nudges from you to keep going is really just a favor someone’s doing you, not a habit that’s stuck yet.

Impact. Is the actual output better, or is the person who owns it just moving the same amount of work around? For the reporting summary, that might mean catching a dip in campaign performance a day earlier, because the context sentences forced someone to actually look at the number instead of copying it. It might mean nothing changed except who spends the fifteen minutes. Both are honest answers. Only one of them justifies building a second workflow.

Who’s actually watching this changes depending on what the workflow touches. For the reporting summary, it’s whoever owned the Friday email before AI got involved, checking their own drafts. For anything closer to money, like the expense-report style workflows other pieces on this site cover, it’s usually whoever already signs off on spend, not a generic “the team lead.” Naming the reviewer by role, not by “someone,” is most of what keeps a checkpoint from quietly dissolving into nobody’s job.

For the broader shift in how small teams work once one workflow like this is running well, our piece on moving from AI experimentation to AI advantage covers what changes at the team level. If the goal is eventually running several workflows like this at once, our piece on building an AI-powered founder’s C-suite looks at that from a founder’s seat. And if the task itself genuinely needs to hold a goal and decide its own next step, rather than follow a fixed sequence the way the reporting summary above does, our practical guide to building an AI agent is the next read, not this one.

Pick the one task from your own week that scores well on the fit test above. Map it by hand, on paper, before you open anything. Name the checkpoint and the person who owns it. Run it for a month. Then, and only then, decide whether it’s earned a second workflow next to it.

Sana Mian, Co-Founder of Future Factors AI

Sana is an AI educator and learning designer specialising in making complex ideas stick for non-technical professionals. She has trained 2,000+ learners across corporate teams, bootcamps, and keynote stages. Future Factors offers AI Bootcamps, Corporate Workshops, and Speaking & Consulting for businesses ready to adopt AI without the overwhelm.

More about Sana →