The AI Workflow Investment Screen

This is Part 1 of a short series, written as a primer for a general reader. Later parts may return to the same ground with material from upcoming teaching — counterpoints, elaborations, and classroom cases. This part stays basic on purpose.

It is not a playbook for how most software organizations actually ship AI. In practice, capability often starts with individual engineers building something that works, then proposing larger integrations upward. The people at the top are rarely sitting with a blank wishlist and a formal "screen." If you already work that way, little here will surprise you.

What this first part offers is simple enough to feel almost embarrassing: before treating an AI idea as a serious project, say whether the system should run the work alone, help a person, or be left alone for now. Call those labels automate, assist, and ignore. The rest of the page is vocabulary, a few questions, and examples. Useful, maybe, if the conversation around you is still stuck on model brands and demos.

The one-line rule is:

If the workflow is not worth changing, it is not worth automating.

That is the whole idea. The sections below unpack it without pretending it is advanced strategy.

Where the simple confusion shows up

Even when engineers build bottom-up, non-technical conversations often start with a wishlist. Picture a meeting after a vendor lunch. Sales wants account research automated. Support wants ticket summaries. Finance wants less hand-checking of invoices. None of those requests is foolish. By the end of the hour they sit under "AI roadmap," and the talk has shifted from what work changes to which tool to try. The labels below are a way to slow that shift for people who do not live in the codebase.

Three labels: automate, assist, ignore

This table is the whole product of the primer. For any AI idea, pick one label for how much the system is allowed to do.

The labels are easy to misuse. Almost any project can be called "assist" and sound careful. The label itself costs nothing. What it leaves out is the work after you pick one: someone still has to review drafts, spend attention, and trust output they did not write. The questions below are only a checklist for a general reader, not a substitute for how engineers actually validate systems in production.

Four questions (optional checklist)

If you want more than a gut feel before you endorse a pilot, answer these in plain language. Engineers will often already know the answers from building the thing. The point of writing them down is shared understanding with people outside the build.

1. What decision improves? Name the decision the workflow is supposed to improve (for example: which account to pursue, which ticket to escalate, which claim to file, which exception to approve).
2. Does the work repeat? If the task does not recur, the organization will have little chance to compare outcomes or correct course across instances.
3. What does the company know that a generic AI tool would not? If the honest answer is "nothing," the project may still save time, but it is unlikely to produce an advantage over competitors who can buy the same tool.
4. Where does responsibility stay human? Name the role that signs off, escalates, or is accountable when the output is wrong. The answer should be specific enough that no second meeting is required to interpret it.

Demonstrations and pilots serve different purposes. Both are more useful after the four answers exist. A demonstration shows whether a tool can perform a task under selected conditions. A pilot runs the tool on the organization's own cases long enough to show who approves outputs in practice, and what the organization does when the system is wrong with high confidence on a consequential case.

Where the idea comes from (briefly)

None of this is original management theory. Information systems research has long said that tools help when they match the task (Goodhue and Thompson, 1995). Automation and "helping a person" can blur after launch (Raisch and Krakowski, 2021). When AI drafts look finished, review work often just moves to the next person in the chain (the pattern HBR and BetterUp call "workslop"). The labels above are a plain-language way to keep those points in view. Source notes at the end list the academic and practitioner references if you want them.

What AI changes in ordinary work

For ordinary office AI, the investment question is where the tool sits in the chain of responsibility once it is used every day. Whether models can draft, retrieve, summarize, or run narrow procedures is largely settled. On many routine tasks they can, and that already changes the cost of those tasks.

Take a sales brief prepared the night before a call. A model can pull the company's latest funding round, a product announcement, and three plausible objections into a clean one-pager in minutes. That is real time saved. What the brief cannot settle is whether this account matches the customers the firm has actually closed, or whether a senior rep would walk away after the first discovery call. Refunds and pricing show the same split. Policy text is easy to summarize; deciding when to break policy for a long-time customer who is about to leave is not. Pricing inputs can be assembled quickly, but what a price is meant to signal about the company still has to be owned. Capability is usually easier to establish than accountability. Accountability placement decides whether the tool should be bought and how it should be governed.

Three ordinary cases

Three common commercial workflows show how the same screen produces different decisions. Account research is usually assist. Support policy lookup can often be automated narrowly. Strategic pricing should usually stay ignore or assist-only. Each case meets the four questions differently.

Account research before a sales call is the familiar scramble: company news, funding history, product signals, executive changes, likely objections. AI can assemble the public layer of that packet before the rep finishes coffee. Any real advantage usually comes from proprietary knowledge: which triggers have historically led to revenue, which objections kill deals, which impressive accounts never close even when the deck looks perfect. Those judgments should stay with a person who has sat in the failed calls, not only read the brief. The system can prepare the packet. It should not own the pursuit decision.

For support policy automation, the main risk is the exception path, not the average ticket. Most tickets are repeated, bounded, and easy to check after the fact, so an AI system can retrieve the policy and draft a reply on mainstream work. Exceptions differ in kind. A refund commits money. A security or legal ticket can create liability. A customer who has renewed for six years and is now furious often needs judgment about tone and discretion that is not written in the policy page the model retrieved. If those cases are not routed to a person before the system answers, the organization finds the failure only after the reply or payment has gone out. Narrow automation is justified only when the mainstream path is automated and the exception path is specified in advance: what counts as an exception, who receives it, and what the system may not do while waiting.

Strategic pricing fails the screen more often because it is easy to mistake for a calculation problem. A pricing working group can fill a room with competitor tables, discount histories, margin math, and scenario spreadsheets. Those materials look like analytical work software handles well, so the temptation is to ask a model for the recommended number. The screen focuses on another aspect of pricing. Pricing is also a choice about market position, which customers the company is willing to lose, how sales will sell the number in a live negotiation, and what procurement friction the firm will accept. An AI system can gather inputs and draft scenarios for those choices. Letting it produce the recommendation risks treating a strategic tradeoff as if a completed table had already resolved it.

Four control points in an AI workflow

An AI workflow usually contains at least four permissions that product demos treat as one feature: producing an output, recommending an action, taking the action, and learning from the outcome. Those are separate control points. Governance fails when an organization approves them with a single decision. A product demonstration can present them as one continuous step. In production they separate again, and each layer can fail on its own.

Walk a single refund through the chain. Drafting a reply is an output decision. Sending that reply places the company's voice on record with the customer. Issuing money moves cash. Then comes the quiet step that rarely appears on the pilot slide: someone adjusts policy because that refund "worked," and the new rule applies to the next hundred cases. That last step is learning. If a system executes and learns without explicit controls, a manager's sign-off on a recommendation is weak control. Governance has to cover each permission, not only the draft that looked fine in the demo.

Use the label at the end, not the start

Apply automate, assist, or ignore after the four questions are answered, not before. Used that way, the label is an operating choice with consequences for staffing, review, and accountability. It is not a decorative taxonomy on a vendor slide.

• Automate the repeated work, inside a narrow scope, with an exception path defined in advance.
• Assist the valuable work where judgment, taste, risk, or relationship context needs to stay visible to a person.
• Ignore the work with weak context, unclear ownership, costly failure modes, or no named decision behind it.

A quick test before the pilot

A short written test is enough to decide whether a pilot is premature. Before approving the next AI pilot, ask the team for one paragraph that names five things:

• the business decision the workflow is meant to improve;
• the person who owns the changed workflow;
• the separation between drafting, recommending, and acting;
• the evidence that would count as a real improvement;
• the condition under which the company will stop.

If the team cannot write that paragraph, the tool is probably premature, regardless of what a demonstration showed. Delaying a purchase can feel slow relative to a vendor timeline, especially when a pilot is already booked for next sprint. In practice the delay is often cheaper than spending a quarter learning that the organization automated a task nobody had agreed to redesign, then staffing the cleanup.

Closing

If you take one thing from this page, take the table: for a given piece of work, should the system automate, assist, or be ignored? The questions and control points are only ways to keep that choice honest. Engineers building bottom-up will often have already lived the answer. The primer is for everyone else still hearing only model names and demos.

If the workflow is not worth changing, it is not worth automating.

What may come next

Part 1 stops at the basic vocabulary. Later parts in this series may return with teaching material already queued: counterpoints (including how bottom-up engineering changes who needs a "screen"), classroom cases, and elaborations that this primer deliberately leaves out. Those pieces will link back here when they are published.