The Founders ReportIntelligence for founders who build
Home/The Signal/Signal Essay
The Signal

Why an AI Workflow Gets Dropped After the Demo

Why an AI Workflow Gets Dropped After the Demo
T
Written by

The Signal Desk

The Founders Report

A demo can end as soon as the AI produces a usable draft. The person doing the job still has to check it, correct it and put it where the next person can find it. If those steps take longer than the old method, dropping the workflow can be the right call.

Zapier's account of its own rollout describes pausing regular work for a company-wide hackathon. It also describes giving employees guidance on which tools and data they could use, and providing an internal place to find help. In its engagement surveys, Zapier says 63 percent of employees reported using AI in daily work in late 2023, rising to 77 percent by the end of 2024. Those are self-reports. They don't tell you how much of the increase came from the hackathon or whether a particular workflow saved time.

BCG's 2025 AI at Work survey found higher regular use among employees who received at least five hours of training and had access to in-person training and coaching. That's a survey association, not a reason to prescribe five hours to every team. For a small trial, start by making time for people to practice on the job they are being asked to change.

Compare the whole job

Consider a hypothetical support team that prepares a weekly summary of recurring issues for its product manager. Before changing the process, ask the person who writes it to record the time from gathering the tickets to posting the finished summary. Have the product manager flag missing issues or conclusions they cannot trace back to a ticket. Keep that check.

Set aside one working session to try the draft on approved material. Give a named teammate time to answer questions and change the workflow, rather than expecting the writer to repair it every Friday. If the tool groups unrelated issues under one label, the owner can examine the tickets with the writer and decide whether changing the input would help. If the team cannot use the necessary ticket data in the approved tool, keep the manual process until that changes.

Give the reviewer a clock too. A ten-minute saving for the writer is a loss if the product manager spends twenty extra minutes opening tickets to check whether the report has confused two customers with different problems.

Log the combined time for each report, including any work the trial creates for the teammate who maintains it.

Decide before the novelty wears off

For this hypothetical trial, suppose the team agrees to keep the workflow only if it saves at least 15 minutes on three of the next four reports, including time spent correcting the draft. Each issue the product manager is asked to act on must still have a ticket reference. The numbers are an example of a local decision rule, not findings from either source. Give the writer permission to use the old method when the new one is slowing them down, and record why they switched.

At the end of the month, review the finished reports beside the time records. Drop it if corrections erase the savings. If the time saving survives and the product manager can still trace the issues, keep the draft step and make its maintenance part of the owner's job so the writer knows who to call when the inputs change.