Resources

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.

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.

‍

Most leaders already sense that friction exists in their organization. The hard problem is prioritization: across dozens of workflows and hundreds of potential improvement opportunities, where do you focus first?

The workflow scorecard is how we answer that question.

The idea is straightforward. For every workflow you want to understand, say handling a customer escalation, onboarding a new hire, or prioritizing an engineering backlog, you collect structured feedback from the workers running it: how much time the workflow takes, how much effort it demands relative to the outcome, where things get stuck, and what is helping.

That data feeds a scorecard for each workflow: a quantified picture of where the workflow stands across dimensions like time spent, friction level, tool effectiveness, and clarity of process. Every workflow gets a score, and because the methodology is consistent, workflows can be compared directly.

That is where the prioritization power comes from. Instead of relying on the loudest voice in the room or the most recent anecdote, you have evidence that one workflow carries high friction and high strategic importance and should come first, while another carries moderate friction but low impact and can wait.

The scorecard also tells you why a workflow is struggling, not just that it is. Root causes surface in the data, whether the issue is a tool that does not work as needed, an unclear process, an under-resourced role, or a data gap that creates constant rework. Each root cause routes to a different owner: the AI team, IT, Ops, or HR. That replaces siloed dashboards where each function sees a different slice of the same underlying problem.

And because the scorecard is based on worker feedback that can be collected repeatedly, it becomes a tracking mechanism over time. Intervene on a workflow, remeasure six weeks later, and see whether the score improved. That is your evidence the intervention worked, and your signal to scale it.

Most organizations make transformation investments without this kind of feedback loop. They deploy and wait for lagging indicators to confirm what they suspect. The workflow scorecard makes the feedback loop continuous.

There is a framing issue at the center of most AI evaluation efforts, and it is distorting the signal.

Leaders are asking whether the model is performing: accuracy, latency, usage.

The more useful question is whether the work is performing better. For every workflow being transformed by AI, and for every role involved, the real question is: did this make it easier and faster for workers to reach a better outcome?

These are different questions that require different data, and they lead to very different conclusions about whether an AI investment is working.

A CIO magazine article on rescuing failing AI initiatives put it plainly: leaders need to shift from model performance metrics to workflow performance metrics. The technology can be working perfectly and the work can still be worse. Employees may be using the tool, as clicks and logins confirm, but if they are also doing more manual review, navigating more unclear handoffs, or spending more time reconciling AI outputs with reality, adoption is not translating into value.

The organizations making genuine progress on AI ROI have learned to separate these two signals. Model performance tells you whether the technology is functioning. Workflow performance tells you whether it is creating value in the context of real work.

Workflow performance is harder to measure. It requires getting inside the work itself: how effort is distributed, where time goes, and what has improved or gotten worse since the AI was introduced. System data captures some of this, but much of it requires direct input from the workers running the workflows, who know the full picture in a way no dashboard can reconstruct.

The shift also matters for how organizations diagnose problems. When AI underperforms, leaders often look at the tool first: model quality, prompt engineering, integration. Those are worth checking, but more often the diagnosis points to something surrounding the AI, such as a workflow that was never redesigned to accommodate it, a role left unclear, or a data source the AI cannot access.

Those problems are invisible at the model level. They only become visible when you measure the workflow.

For every AI deployment worth measuring, build in a workflow performance baseline before go-live, then remeasure at regular intervals. The delta between those measurements, not the model metrics, is where your ROI signal lives.