Resources

If you lead a customer care team, a sales force, a field operation, or a shared services function, the last few years have probably looked something like this:

AI tools got deployed to your team. You were consulted on the use case, maybe. IT handled the rollout, HR handled the change communications, and the AI team tracked adoption. Then everyone waited to see if your numbers moved.

Sometimes they did. Often they did not, and when they did not, the conversation got complicated fast.

This is the operational leader’s AI problem, and it is different from the one the AI team is solving.

The AI team is asking whether the tool is being used and whether the model is performing. Those are legitimate questions, but they are not yours. Your questions are whether your team is reaching better outcomes, whether the work is getting easier and faster, and whether your people can do the job better than they could six months ago or are simply doing it differently, with the same friction and a new interface on top.

Most organizations do not have a clean answer to those questions. The dashboards that exist were built to track tool adoption, not workflow performance. They tell you what your people click, not what gets in their way.

Here is what we see consistently across the operational functions we work with: the AI is often the least of the problem. The friction defeating productivity was there before the AI arrived: unclear decision rights, handoffs that break down between roles, data that lives in three systems and gets reconciled by hand, and escalation paths nobody can quite explain. These are workflow problems rather than technology problems, and they do not show up in an adoption metric.

What operational leaders need, and rarely have, is a clear picture of how work actually unfolds for the people on their teams, the lived version rather than the process map: where time goes, where effort concentrates, and what people work around every day and why.

That picture has two immediate uses. First, it tells you where to push back when AI investments are not delivering: not “the tool doesn’t work,” but “here is the specific friction point in the workflow preventing adoption from translating into outcomes.” That is a conversation you can have with specificity instead of frustration.

Second, it gives you the evidence to make the case for the operational changes your team actually needs, such as process clarity, role definition, and decision rights, which often get deprioritized in favor of the next technology deployment.

You are the leader accountable for outcomes, and your team runs the workflows. They know exactly where things break down. The question is whether anyone is asking them specifically, regularly, and with enough structure to turn their answers into something you can act on.

If the answer is no, that is where to start.

McKinsey’s State of AI research identified something significant: the top 6% of organizations in AI performance are nearly three times as likely as others to fundamentally redesign their workflows when deploying AI. The difference is structural, not marginal.

The instinct in most organizations is to identify a use case, select a tool, stand up training, and launch. That is process thinking: sequential, organized around the technology. AI high performers do something different. They understand the work before they change it, and they treat workflow redesign as a precondition for successful deployment rather than a follow-on activity.

What does workflow redesign actually mean in practice? It is worth being specific, because the term gets used loosely.

It does not mean updating process flows, changing the technical architecture, or revising job descriptions. All of those may happen as a result, but they are outputs of workflow redesign rather than the thing itself.

Workflow redesign means looking through the worker’s lens at how a specific goal gets accomplished, and deliberately defining what changes in that sequence now that AI is part of the picture. That means deciding where AI and human steps should be restructured to reduce handoffs, where AI creates output requiring judgment the current process does not account for, what can be collapsed, automated, or eliminated, and what new friction the AI creates that must be designed around.

This requires a clear view of the workflow as it currently exists, the real version rather than the process map: where time goes, where effort concentrates, and what workers do that appears in no documentation.

Most organizations do not have that picture when they deploy AI. They are redesigning from an abstraction rather than from reality, and the gap between the intended workflow and the lived one is where AI deployments lose their ROI.

The organizations pulling ahead treat workflow intelligence as infrastructure, something built and maintained rather than commissioned once for a transformation initiative. They go into every AI deployment with a clear, worker-informed view of the workflows they are about to change. They measure, redesign, and remeasure.

That discipline is what separates the 6% from everyone else.

Global Business Services leaders are operating under significant pressure. They are being asked to accelerate digital and AI transformation, improve employee experience, reduce cost, and demonstrate measurable ROI, often simultaneously.

The data most of them are working from is not built for that moment.

Process mining, SLAs, and ticketing systems are the standard measurement tools in GBS environments. They are valuable, but they are lagging indicators that tell you what went wrong after it happened. They cannot show where the next problem is forming, or why workers are starting to disengage from a new tool before that disengagement reaches your service metrics.

Friction data is a leading indicator.

When GBS teams collect direct feedback from the workers running key workflows, in HR service delivery, finance processing, IT support, and procurement, they get signal early: which workflows carry the most friction before it becomes an escalation, which AI tools are creating confusion before it shows up in productivity numbers, and where handoffs between shared services and business units are breaking down before it becomes a relationship problem.

That early signal is what de-risks transformation. In most underperforming GBS AI deployments the technology works. It meets a workflow it was not designed for, creates friction the deployment team did not anticipate, and underperforms against the business case while the organization waits for lagging metrics to explain why.

Friction data short-circuits that cycle. You find the problem while it is still a friction point rather than a failure, and you know which workflows to fix, which tools to adjust, and which roles to clarify before the investment case erodes.

Successful GBS transformation in the AI era pairs technology deployment with a feedback loop that shows whether the technology is working for the people it serves. That is how teams free up hours of productive time per worker per day, accelerate AI tool adoption, and close the silos that make service delivery a maze.

It starts with being willing to look at friction before it becomes a failure.

Most organizations know they need better insight into how work gets done. Fewer have made it a discipline rather than a one-time exercise.

Workflow intelligence is best understood as a management discipline, comparable to financial controls, rather than a measurement product. Financial controls exist so that management knows whether the business is performing and who is answerable when it is not. Workflow intelligence does the same for work. It continuously measures how employee workflows are performing, identifies friction, attaches each cause to an owner, and tracks whether interventions improve anything. It is moving from a competitive advantage to a baseline requirement, and here is what it looks like when organizations build it well.

It starts with specific workflows, not the whole organization.

The most effective approaches do not try to map everything at once. They start with the workflows that matter most strategically: the ones being changed by AI, carrying the highest friction, or tied to outcomes that matter this quarter. Focus creates signal, while measuring everything produces noise.

It uses worker input as the primary data source.

System data has a role, but the most valuable workflow intelligence comes from the people running the workflows: what takes time, what gets in the way, what changed when the new tool went live, and what they would change if they could. The data is only valuable if it is collected specifically, briefly, and regularly rather than buried in an annual engagement survey.

It quantifies so you can prioritize.

Qualitative research produces insight; quantitative data produces decisions. Effective workflow intelligence gives you a score, not to grade employees but to compare workflows against each other and identify where to focus limited capacity for improvement. Every hour a cross-functional team spends on the wrong problem is an hour not spent on the right one.

It routes insights to the right owners.

Workflow data touches multiple functions. AI teams need to know where tools are not working, IT where data access creates friction, Ops where process steps create bottlenecks, and HR where role clarity or capacity is the constraint. The data should flow to whoever can act on it instead of sitting in one team’s dashboard. This is where the discipline differs from a reporting product: the point is not to inform owners but to make workflow performance part of what each owner answers for.

It tracks whether interventions work.

This is the piece most organizations are missing. They identify friction and make changes, then never close the loop. Workflow intelligence should include a remeasurement cycle: after an intervention, does the workflow score improve? That confirmation is how you build the evidence base for scaling what works.

Building this does not require a multi-year program. Organizations can start within a specific function or workflow family, build credibility with early results, and expand from there. The data layer is the easy part. What makes it a discipline is the management decision that workflow performance is something owners answer for.

For many organizations, agentic AI is already here.

AI agents are beginning to execute tasks that used to require human judgment: searching for information, completing forms, generating reports, coordinating handoffs, updating records. The scope is still limited, but the trajectory is clear. Over the next several years, agents will take over more of the individual steps inside the workflows your people run.

This creates an enormous opportunity and an equally large blind spot, unless organizations build the feedback infrastructure now.

As AI agents handle more tasks, the human’s role in a workflow shifts from executing individual steps to overseeing, directing, and resolving exceptions. The locus of human effort moves from execution to judgment and coordination.

That shift makes workflow-level visibility more important, not less. You need to know whether the agent is making the workflow faster and easier for the human working alongside it, whether the handoff between agent and human works cleanly, where exceptions concentrate, and what the agent produces that humans then have to fix.

None of these questions can be answered by monitoring the agent alone. System logs record what the agent did, not how that landed for the worker, what downstream friction it created, or whether the human experience of the overall workflow improved.

The organizations that will manage the agent-augmented workforce most effectively will be the ones that built a workflow feedback loop before the agents arrived, not after.

The data you collect now about how workers experience their workflows becomes the context your agents need to improve. If you have not captured that data, your agents are operating on assumptions, and assumptions at scale and speed compound into expensive problems.

There is also a strategic dimension. The organizations that develop strong workflow intelligence today are building a capability that gets more valuable as AI takes on more. Every workflow data point you collect now is context that makes future AI deployments better targeted and better adopted.

Start capturing workflow feedback at scale now, because the decision only gets harder as the pace of change accelerates.

High attrition is almost always treated as an engagement problem. You run a survey, find out people are dissatisfied, and invest in manager training, benefits, and culture programs. Sometimes it helps. Often it does not, because the root cause was never engagement but friction.

A telecom company came to us with a retention crisis. Low engagement was driving attrition at an unacceptable rate, particularly among entry-level employees. Hiring and onboarding new people was costly, and the situation was becoming untenable. The standard levers, compensation reviews, engagement scores, and pulse surveys, were not pointing to a clear fix.

We took a different approach: looking at how work actually unfolded for these employees, and where it broke down.

What emerged from the data was specific and actionable: a significant friction point around career progression. New entry-level hires could not get clarity on what advancement looked like. They could not have the conversation with their manager, because managers lacked the information, did not prioritize it, or had no structure for it.

These employees were not leaving because they disliked the company. They left because they could not see a path forward and nobody was helping them build one.

Once the root cause was clear, the organization could address it directly. They redesigned onboarding to include structured career conversations and made those conversations a defined part of the manager’s role rather than a nice-to-have.

Attrition began to improve. A specific diagnosis had made a specific intervention possible.

This is the difference between measuring sentiment and measuring the workflow. Engagement surveys told this company that people were dissatisfied. Workflow data told them why, and what to do about it.

When attrition spikes, the instinct is to look at culture and compensation. Those matter, but before investing in solutions it is worth asking whether a workflow you have not yet seen is driving the problem.

A large financial firm introduced chatbots and code assistants to its IT division. The productivity case was solid. Research consistently shows AI can improve output on complex tasks by more than 50%, and the company had every reason to expect gains.

What they got was flat productivity. Six months post-launch, the numbers had not moved.

Particularly puzzling: junior developers, who typically benefit most from AI assistance, were seeing the worst outcomes. Senior developers were adapting while junior developers struggled.

The firm did not know why. Their data showed adoption: logins, usage rates, prompts submitted. It did not show what was happening inside the work.

That is where we came in.

By collecting workflow-specific feedback from developers on what was working, what was not, and where they got stuck, we identified two friction points hitting junior developers especially hard.

First, the new AI chatbots could not access the data repositories developers needed to do their work. Queries came back incomplete or irrelevant, and developers had to source the context manually, which took longer than the pre-AI process.

Second, the code assistants generated output that required mandatory manual review, a step that had not been part of the original workflow. For junior developers, less experienced at quickly assessing code quality, the review was time-consuming and stressful, a new obligation layered on top of existing work.

In both cases the AI made the workflow more complicated, and it did so for the people least equipped to absorb the added complexity.

With these specific friction points identified, the firm had a clear target. The goal was not a vague mandate to improve AI adoption. It was to fix the data access problem and fix the review loop, two concrete and solvable problems.

The fixes took time to implement, but once in place, the productivity picture changed. The organization ultimately realized $5.4 million in annual savings, the gains projected from the outset, delayed not by the technology but by workflow friction they had not known to look for.

The AI worked from day one; the surrounding work took a few months to catch up.

There is a pattern in underperforming AI deployments that keeps surfacing across industries and functions: the technology works while something around it does not.

Here are three examples from organizations we have worked with directly.

The sales team with more leads but no more time to sell.

A company deployed AI prospecting tools to increase pipeline and improve close rates. Adoption was solid, but sales leaders were still spending significant time handling fulfillment escalations and rescuing accounts after the handoff to delivery. More leads came in without more capacity to pursue them, because the post-sale workflow was still broken. The AI improved the front of the workflow while the back end remained a constraint nobody had addressed.

The customer care team that couldn’t answer.

A company deployed a generative AI assistant in their contact center to reduce average handle time. Agents were using it, but they kept escalating calls, not because the AI produced wrong answers but because decision rights were unclear. Agents did not know which answers they were authorized to give. The AI could draft a resolution, but the human could not act on it without going up the chain. A structural ambiguity in the workflow defeated the tool’s value.

The manager who now had four wrong doors.

A company deployed an AI HR assistant to reduce inbound support tickets. But managers were now choosing among four channels, the chatbot, SharePoint, email to their HRBP, or a ticket, and getting conflicting answers from all of them. The company had not simplified the experience; it had added another option to an already confusing landscape. So managers did what people do when the system fails them: they went back to the relationship they trusted. HRBP volume did not go down.

Three functions and three tools shared one underlying dynamic: AI dropped into a workflow problem the organization did not fully see before deployment.

In each case, the variable that needed to change was the workflow, not the AI. And in each case, the friction that defeated the AI had been present long before the AI arrived. It had simply never been measured or addressed.

All three were diagnosable and fixable, but only after the workflow became visible.

Six months after deploying an AI coding assistant to 1,200 developers, technology leaders at a Fortune 100 telecommunications company were puzzled.

Developers generally liked the tool, and code was being generated faster. But products were not reaching customers any sooner. Executives had expected significant improvements in time to market, and they were not materializing.

“I have tons of data about tools and processes,” one tech leader said, “but I still can’t see where and why things are getting stuck.”

That is when they brought us in to go deep on the reality of how work was actually getting done.

Using workflow-specific surveys, we collected data from a statistically meaningful subset of developers on how they actually spent their time: where effort concentrated, which tools were helping and which were not, where handoffs slowed things down, and what they were working around.

Three weeks in, we had answers, and they did not point to the technology. Coding had never been the bottleneck.

Developers were spending the majority of their time managing shifting scope, waiting on unclear priorities, and navigating slow handoffs across teams. The AI coding assistant had made one part of their work faster but had not touched the parts causing delays. Code was written faster and then sat in a queue.

Leaders knew anecdotally that prioritization and handoffs were painful. What they lacked was quantified, scaled evidence of how pervasive the problem was across workflows, teams, and levels of seniority. The engagement turned those impressions into data.

With that data, the company clarified decision rights, simplified backlog prioritization, and collapsed overlapping roles. Time to market then started to move, improving 10% and counting.

Looking back, one of the engineering leads described it this way: “What we did initially was like giving employees a Ferrari in Manhattan congestion. The AI tool is powerful, but the bottlenecks prevented speed.”

This is the pattern we see repeatedly: AI tools that work as designed but fail to deliver against business expectations, because the workflows surrounding the AI were never examined. The technology gets blamed while the real issue sits elsewhere.

Before this engagement, the congestion could not be seen. Once it was measured, it could be fixed.

‍