Most AI workflow initiatives do not stall because the technology can’t perform the task. They stall because the organization hasn’t made key operating decisions that the technology’s success depends on.
Every day, inside of 3Pillar’s Helix Forward team, we’re working with business leaders to expand their thinking of what’s possible, refine understanding of what it takes to change, and reimagine workflows for the AI era. Being so hands-on with so many companies in this AI transformation, we’ve learned what it takes to see meaningful outcomes arrive on schedule.
Most AI workflow initiatives don’t stall because the tech can’t perform the task. They stall because the organization has not made the operating decisions that the technology depends on.
A team may use AI to draft a customer response, prepare some approval request, generate code, reconcile data, or summarize a case study. But faster task completion does not automatically produce a faster decision, a better customer outcome, lowered operating cost you can measure, or more capacity. If all of the jobs-to-be-done still enter the same queue, rely on poor upstream inputs, require the same reviews, or create outputs that downstream teams just aren’t prepared for, the overall results will likely underwhelm.
That’s the main mistake in much of the current AI conversation: treating today’s workflow as a specification for automation.
In reality, many workflows are a sort of collection of inherited constraints, informal workarounds, duplicated controls, and unclear decision rights. Accelerating them can make the old process run faster without making the business work better.
Before committing to an AI-enabled workflow, leaders need answers to five questions:
- What outcome must improve?
- What happens upstream and downstream—and how does the proposed change affect it?
- What work should be removed, redesigned, or deliberately retained?
- Who has the authority to authorize those changes?
- Who will need to work differently, and what will make the new way stick?
These questions are simple, but they expose the decisions that determine whether an AI initiative becomes a useful pilot, a scalable operating change, or just a faster execution that does nothing to evolve business as usual.
An incomplete answer here usually tells you where the next investigation or conversation should focus. What may be required is anything from a simple process decision, testing change with a user trial, and/or often a change in scope before technical development proceeds.
1. Thinking of outcomes, beyond the task
| QUESTION | WHAT THE PROPOSAL SHOULD ESTABLISH | LISTEN FOR ANSWERS THAT INDICATE CONCERN |
|---|---|---|
| What outcome must improve? | The proposal must establish a meaningful business outcome, including the conditions required to achieve it. | The outcome is operational but hard to tie to a business outcome. Example: If a task gets faster but the business result feels the same, it’s likely not been thought through deeply. |
We do a lot of software development transformation work at 3Pillar. It’s a useful proxy for thinking about AI workflow automation.
For those in the space, it’s quickly become consensus that code acceleration alone isn’t enough. Yes, an engineering team can produce code faster but if review capacity and release approvals remain unchanged, nothing’s shipping faster. And where’s the progress there?
That observation came up in our discussions within the 3Pillar Helix Forward team recently. The same fundamental truth about dependencies around engineering work also applies in finance, operations, customer experience and any other business domain worth evolving.
Consider this illustrative approval process below.
Assume preparing some internal request takes two days, waiting takes five, and actual review takes one. Eliminating preparation time would remove a quarter of the total elapsed time, but if the business had a “four-days” target, that would still be out of reach without changing something else.
And what if changing preparation time increased the actual volume of requests in this hypothetical example? We can assume wait times would only increase as a result of that.
The ecosystem and its net outcomes are, for this reason, pretty useful to establish before debating tools. AI automation for “preparation” might still deserve investment because it is expensive, error-prone, or consumes scarce or expensive expertise, but the sponsor needs to distinguish those benefits from the promised improvement in decision speed.
The target determines which dependencies belong in scope.
Pressure-test the implied ROI: If this activity took no time tomorrow, what would still prevent the business from getting the result it needs?
Follow the answer to that question far enough and you’ll usually find an important decision that someone needs to make.
An answer like “it wouldn’t work if approvals are slow” would need more investigation.
Evidence that routine requests just sit in a queue until a weekly meeting gives the sponsor something specific to look into. Changing the meeting cadence, approval thresholds, or delegated authority would each have different consequences for capacity and control.
2. Considering the real, full workflow
| QUESTION | WHAT THE PROPOSAL SHOULD ESTABLISH | LISTEN FOR ANSWERS THAT INDICATE CONCERN |
|---|---|---|
| What happens upstream and downstream, and how does the outcome change it? | The proposal must establish what the targeted process depends on upstream (inputs, timing, data quality, handoffs) and what depends on it downstream as well. | The process is described like it stands alone. Example: If some proposal automates invoice approval but never mentions that approvals feed monthly closing (or that upstream data arrives late one week in four) the team is treating one step as the whole system. |
One uncomfortable truth AI has exposed is that across large portions of most businesses there is no agreed-to definition of what good looks like, or even of how the work is supposed to get done. This is especially true for knowledge work, where tribal knowledge and instinct rule.
Knowledge work rarely follows a stable, linear production flow. Asking “can we use AI for this, it feels so cumbersome and costly as-is” is a reasonable question, but it often reveals something more basic: the best practices and expectations were never understood in the first place.
Real work happens in a system. A marketing team might be underperforming on a deliverable because of SME chasing, approval hunting, budget questions, integration problems, or a plain lack of buy-in from other parts of the business, and none of that shows up if you only look at the team’s own focus or creative time. The same is true of nearly every workstream.
What one team does has consequences for other teams. Meaningful change means the functions downstream (loosely speaking, since work rarely flows like a waterfall) also have to be ready to operate in this new reality, and often the ones upstream do too.
3. Decide which work deserves to stay
| QUESTION | WHAT THE PROPOSAL SHOULD ESTABLISH | LISTEN FOR ANSWERS THAT INDICATE CONCERN |
|---|---|---|
| What would be lost if each step disappeared? | For every step, what specifically would stop working or get worse without it, and the least work and human involvement that preserves that. | Every existing step is assumed to carry over. Example: If the plan automates a task exactly as it is performed today, including the manual workarounds that only exist because the old system was slow, the process was never redesigned, just sped up. |
Just because someone in a functional workflow commonly copies and pastes from spreadsheet A to spreadsheet B doesn’t mean that’s a task you need to automate. Often, what seems like an obvious automation candidate is important in hidden ways, and just as often a step that looks essential only exists because of how the workflow happens to run today.
To set the right path, walk through an actual case with the people doing the work and understand how and why everything works the way it does. The business leaders driving the change are rarely exposed to these flows.
Two questions can help here:
- First: If this step disappeared tomorrow, what specifically would stop working or get worse?
- Second: What is the least amount of work, and the least human involvement, required to preserve what actually matters?
The first question separates the step from the outcome it provides. The second keeps the team from rebuilding the step in software when a smaller answer exists.
Keeping the spreadsheet example, you might remove some workflow that creates a second spreadsheet only to recreate information already available. You might collapse operations related to a reconciliation process caused by competing definitions. Maybe the process just needs agreement on the data. And you might retain or even augment certain manual review, but that needs a named owner to decide what evidence and judgment must remain in the workflow. Automation can then be designed around the agreed upon future-state workflow design.
This examination also changes the economics.
Removing unnecessary work can eliminate its maintenance and exception handling as well as its execution time. Preserving it in software creates an ongoing obligation to support something the business may no longer even need.
4. Make authority specific enough to use
| QUESTION | WHAT THE PROPOSAL SHOULD ESTABLISH | LISTEN FOR ANSWERS THAT INDICATE CONCERN |
|---|---|---|
| Who can actually authorize the change? | The proposal must establish specifically which owner has the authority to make the call on the proposed changes. | The sponsor supports improvement but cannot resolve competing requirements. Example: If two teams disagree on what the automated output should look like and the sponsor’s answer is “let’s find a compromise.” |
Using our own organization as an example, an internal automation initiative at 3Pillar recently sent me into conversations with at least ten people. The initiative had executive backing, which implies authority to change things, but after days of effort we were still looking for the person with authority to change the process. This isn’t uncommon in the nuances of real-world work.
Anybody can explore a technical solution with all sorts of passion, but to what end if a fundamental operating decision remained unresolved?
An automation team needs to know who can authorize the changes on which its business case depends, and those people have to be part of the process. Otherwise, you’re chasing your tail. The more useful move is to sort the proposed changes by what they touch, then name three personas for each: who decides, who can stop it, and who has to work differently afterward.
In short, an engineer should be able to find the answer without reconstructing a chain of conversations. That’s a practical standard for whether the organization has given the team enough permission to proceed.
5. Spot test new responsibilities with the people who will have them
| QUESTION | WHAT THE PROPOSAL SHOULD ESTABLISH | LISTEN FOR ANSWERS THAT INDICATE CONCERN |
|---|---|---|
| Who must work differently? | The proposal must establish new responsibilities, tested with users and adjacent teams. Critically, it must also define how this is enforced. | The benefit would rely on behavior nobody has agreed to change. Example: If the projected savings assume that reviewers will stop double-checking the automated result, but no reviewer has been asked or agreed. |
In so many instances we’ve witnessed the frustration experienced around processes that people do not follow because they had no part in defining them. A useful new workflow design has to accommodate the information, time, and judgment available to those persons expected to leverage it.
It’s just like good product leadership. Empathy first.
Merely documenting the standard current state workflow can hide these requirements.
Ask users to demonstrate a difficult part of their flow, which pulls them off of whatever they think is business as usual… some missing information, an ambiguous exception, or a decision they cannot make alone.
Watch where they leave the prescribed usual flow, and look at who they contact. Those details should influence the proposed workflow while it’s still inexpensive to change.
Before expanding a pilot, look for observable evidence:
- The handoff works: The receiving team can use the output without recreating the previous task.
- The exception has an owner: Users know when to intervene and can reach someone authorized to decide.
- The old work can stop: Required controls remain covered, and users can retire duplicate routines without losing information or protection they need.
On this point, managers also need to examine what they reward.
If employees remain accountable for submitting an old report, they’ll definitely have a reason to keep producing it after the new workflow arrives. Likewise, if their own work speed is the core measurable and they find their old way of working to be ‘easier’ than learning the new operations, they’ll just keep doing the old way and never evolve.
Employees already experimenting with better ways to work can help uncover these barriers.
I favor actively finding them (the AI heroes) and cultivating those relationships, giving them context to explain the change and opportunities to bring practical concerns into design. Their initiative becomes more useful when the people who own the process can act on what they learn.
Fund what the evidence supports
The five question framework above will often change what happens in an investment review. In our experience, a proposal that leaves major operating decisions unresolved needs an entirely different commitment (e.g., management discussions, roles and responsibility alignment, etc.) from one ready for a controlled pilot.
Asking the questions early is cheap. A week of conversations with the people doing and receiving the work, plus a sponsor willing to make a few calls, is a small price against months of building toward an outcome the organization hasn’t agreed to. Incomplete answers are useful too. They tell you which conversation to have next.
Teams that get this process right treat the answers to these questions themselves as a sort of spec for the real work ahead. The tooling comes after. They know which business result has to move, what the work depends on and what depends on it, which steps deserve to survive, who is in charge and who is impacted. With those settled, the technical design is actually easier and the results more predictable.
If you’re weighing AI workflow transformation right now (and who isn’t?), put these five questions in front of your team. The answers will tell you more about your odds of reportable success than any tool demo.
