AI Did Not Make the Work Faster
Redesigning the workflow did.
When I tell people we cut a competitive intelligence battlecard process from 60-plus days down to a few days, the reaction is usually the same. They assume the AI did it.
It did not.
The tool was not the transformation. The system the tool operated inside was.
Understanding that distinction is the difference between an AI win and a recurring pattern you can actually replicate.
What the process actually looked like
The team I was working with had a battlecard process that, on paper, seemed reasonable. Gather competitive intelligence, pull information from SharePoint, synthesize it manually, route it through review, hand it off to sales.
In practice, it took over a month per battlecard. Evidence was buried across thousands of SharePoint folders with no consistent structure. Synthesis depended on one person who knew where everything lived. Review happened informally, with no audit trail. And by the time sales received a finished battlecard, the intelligence was often stale.
A prior consultant had tried to fix this with a 12-prompt workflow. The prompts were technically sound, but the workflow required someone who knew how to run each prompt, in which order, how to scope them, and how to catch contamination errors between competitors. It did not remove the bottleneck. It moved the bottleneck to the person operating the prompts.
The primary problem was not the AI. It was the system the AI was trying to work inside.
The real diagnosis
When I started, I mapped the full workflow, not just the AI touchpoints. What I found was that AI had been layered on top of a broken process without changing the process underneath it.
The core issue was the SharePoint architecture. It had been built around how people happened to file things, not around how an AI agent would need to retrieve them. AI agents search by pattern, not by topic. The old folder structure made sense to someone who already knew where everything lived. It did not make sense to an agent trying to retrieve the right evidence at the right time.
The workflow also carried too much judgment in the operator's head. The person running it had to know what to run, what to trust, what to question, and when the output had crossed from useful synthesis into contamination risk.
The review step had no governance either. Approvals happened informally, with no handoff that created accountability. The workflow ended at a document, not at an outcome.
None of those were AI problems. They were architecture problems.
What actually changed
The redesign started upstream of the AI.
First, I rebuilt the SharePoint structure specifically for how an agent retrieves information. Flatter folders, consistent competitor-level naming, date-stamped files, a dedicated battlecard hub where the agent could recognize patterns instead of digging through topic-based clutter. The architecture became the foundation the prompts could actually rely on.
Then I simplified the workflow. The 12-prompt sequence became a three-phase process with built-in quality gates. Phase one produced a sourced evidence summary, with dated citations and flags for anything that needed validation. Phase two drafted the battlecard. Phase three ran a QA check with a staleness flag for pricing data older than six months and a clear pass-or-fail output.
One design choice mattered more than it might sound: one competitor per session. In early testing, evidence from one competitor would bleed into another. The workflow had to prevent that structurally, not depend on the user catching it later.
The review and approval routing was built into the flow, with tracked decisions and a defined publish behavior. The workflow ended with a handoff, not a document sitting in a folder somewhere.
That mattered because the goal was never just a faster asset. It was fresher competitive intelligence sales could actually use in market.
In the redesigned system, a battlecard could move from source gathering to a sales-ready draft in two to three days for a single competitor. But speed was not the most important shift. Quality became consistent across the whole team. The output no longer depended on one expert operator running a complex sequence correctly. Any trained team member could produce a reliable result.
The lesson I keep coming back to
To be clear, the AI capability mattered. A weak tool would not have produced a good result. But capability without architecture was not enough to move cycle time or consistency. The same AI that looked underwhelming inside a broken workflow became genuinely useful once the inputs, sequence, and governance were redesigned around it.
There is a version of AI adoption that looks like this: give a team access to a tool, show them some prompts, measure adoption rate. That version is common right now. And it produces exactly what you would expect. High adoption. Low impact.
The version that produces real improvement looks different. It starts by asking where the workflow is slow. Then it asks why. Then it designs the system the AI needs to do its job well, whether that is cleaner inputs, simpler prompts, or a governance layer that creates accountability at the end.
The battlecard process did not get faster because of the AI. It got faster because the workflow was redesigned. It got more consistent because the workflow was designed so any trained team member could run it, not just the person who knew where everything was buried. The AI made both of those things dramatically more valuable than they would have been before.
That sequencing matters.
A design test worth applying
If your team is using AI tools but not seeing meaningful improvement in cycle time or output consistency, I would not start with the prompt.
I would start with the workflow.
Where is the work slow from request to outcome? Where are the inputs inconsistent? Where does judgment live only in one person's head? Where does review happen informally? Where does the output stop short of the person who actually needs to use it?
Then apply one design test:
Could the busiest, least-technical person on your team run this workflow correctly, without asking for help and without becoming the new bottleneck?
If the answer is no, you do not have a workflow problem yet. You have a dependency dressed up as a solution.
That is worth sitting with. A workflow that only works in expert hands is not a system. It is a single point of failure with better prompts.
Design for the whole team, not the person who built it. Build the workflow so any trained team member can run it reliably. Then the AI has something worth accelerating.
Thanks for reading and stay curious.
Jayme Jenkins is a senior marketing leader who helps B2B SaaS and enterprise technology companies move from fragmented marketing activity to buyer-led growth systems. Her work focuses on GTM strategy, AI-enabled workflows, measurement clarity, and teams that own the work.