{/* Prologue */}

For leaders making the decision

Most enterprise AI investments fail because of the order they are designed in. The technology usually works. The sequence is what's wrong, and it shows up in the P&L, in regulatory exposure, and in customer churn that surfaces a year or more after launch.

Boards approve AI programmes that look successful in execution and produce disappointing results in the business. Audit findings arrive 12–18 months post-launch. NPS drifts downward in ways nobody connects to the transformation. Productivity gains stay on the slide deck.

The cause sits at the design layer. AI transformation is still being designed inside-out, starting with what operations wants to fix, with governance and customer experience added later as separate workstreams.

I have run this both ways. On a mortgage-servicing process, redesigning the associate's role in parallel with the automation took a 25-day turnaround down to four days and cut rework from 8–10% to under 1%. The automation was the easy part. The design sequence was what made the gain hold.

This article makes the case for a different discipline. The Outside-In Triad. Three constraints held simultaneously from the first workflow decision and through the whole programme: governance and risk, people and operations, customer journey.

The strategic implication is direct. The next wave of AI value will be won by the organisations whose design discipline survives contact with their actual business: regulatory, operational, and customer-facing, all at once.

{/* I */}

I · Three conversations I keep having Three organisations, three failure modes, one root cause.

A leader pulls up the transformation dashboard. Eight projects. All green. Twelve months in, benefits haven't materialised. Teams are duplicating effort. Vendors operate in parallel without visibility into each other's work. Data is handled differently across lines of business.

Nobody can point to what's wrong, because individually nothing is. The problem isn't in any single project. It's the absence of structure holding them together.

Across the BFSI implementations I have led and supported, the pattern repeats: multiple workstreams, separate ownership, no central governance. Projects optimise locally and the organisation drifts from its strategic goal. Goldratt named it in The Goal: local optimisation is the enemy of global performance. In AI transformation it shows up in the P&L about eighteen months after go-live.

A second conversation

A different organisation. Design was right. Implementation was smooth. Six months later, adoption sits at 20%. Employees route around the new system. Leadership is confused: the technology works and the logic is sound.

What's missing is the answer to a question nobody asked: what does it feel like to work inside this process every day?

The AI handled the standard case. Every exception landed on the human, who now carried more ambiguity and cognitive load than before. The role itself was never redesigned for that reality. In rule-based automation this is manageable. With AI it is harder, because the outputs are probabilistic and the associate has to judge when to trust the system and when to override it.

A third conversation

Costs came down, average handle time improved, and ops hit its targets. Then NPS started to slip.

The automated phone menu (IVR) saved seconds per associate and added minutes of friction per customer. The chatbot that replaced it could not understand context. Same design failure, newer technology. Customers didn't switch channels. They switched providers.

A good customer experience earns loyalty slowly. A bad one destroys it fast, and the damage outruns the saving. Optimise internal operations at the expense of the customer journey, and the value leaks out exactly where the dashboard never looks. {/* II */}

II · One root cause Three failure modes, one design sequence: built inside-out, with the customer left downstream.

All three designed AI transformation from the inside out, starting with what operations most wanted to fix. The customer was downstream. Governance was a final-stage review. People were expected to adapt.

That sequence is the failure mode.

Transformation that lasts starts from the collision point of three forces held together: the regulatory and governance frame that determines what is sustainable, the people and operational reality that determines what is adoptable, and the customer journey that determines what is actually valuable.

This is the Outside-In Triad.

{/* III */}

III · How this differs from existing frameworks BCG, McKinsey, and Forrester are right about the ingredients. The Triad adds three things they don't.

BCG's 10-20-70 rule correctly identifies that 70% of transformation value lives in people and process. McKinsey addresses strategy and culture. Forrester covers governance and customer-obsessed operating models. These frameworks are right about the ingredients.

All three held at once

Existing frameworks still imply an order: governance first, change management second, customer measurement third. The Triad treats all three as co-equal constraints from day one. A decision that satisfies governance and people but ignores the customer journey is a future problem that has not surfaced yet.

Where the lenses actually collide

BCG and McKinsey operate at portfolio altitude. The Triad applies at the workflow level: loan origination, fraud alerts, returns automation, field engineer escalation. This is where the three lenses actually collide. Modern enterprise teams have no separate strategy team, implementation team, and middle-coordination layer. The person operating the workflow carries all three lenses simultaneously.

Measurement gets redesigned

Most frameworks bolt measurement on at the end. The Triad treats it as a design question: are the metrics being tracked still valid for the new process, or did the transformation change what needs to be measured? Carrying old metrics into a new process is one of the most common and least discussed failure modes.

{/* IV */}

IV · In practice: a customer address change Same technology, same target metrics, two different 24-month outcomes.

Consider one of the simplest workflows in any bank.

A customer wants to update their address. They upload a supporting document, a utility bill, ID, or rental agreement. An associate downloads it, validates the document type, visually checks for forgery, extracts the new address, updates downstream systems.

For a clean English-language document: about two minutes. For everything else: not.

A document in an unfamiliar language: is this a utility bill, a tax notice, a government letter? Classification alone takes five minutes. A non-direct case can run 10–20.

Most banks are now applying AI to this workflow. The two approaches diverge sharply.

Inside-out redesign: Deploy AI document processing. Auto-approve clean cases. Route exceptions to human review. Target reduced AHT (average handle time), reduced headcount, higher straight-through processing (STP). The dashboard improves.

Outside-In Triad redesign: the three lenses change the design from the first decision.

Figure · The same workflow under two design disciplines

Governance	People	Customer
Information-security pipeline for document extraction designed before deployment: where the raw document sits, who accesses it, how it's disposed of.	Before automation, the associate handled a mix of direct cases and exceptions distributed across the day.	The customer doesn't see internal complexity. They see whether it worked, when they will know, and what to do if something is wrong.
For each approval, a plain-language rationale and the evidence the decision relied on are captured in a form a human auditor can read.	After automation, the associate handles only exceptions, all day: ambiguous types, suspicious legitimacy calls. Every case is cognitively heavy.	An immediate, meaningful acknowledgement the customer can act on.
When the AI eventually approves a forged document, the failure-capture mechanism already exists: sampled audits of high-confidence approvals, and a confidence threshold that routes the uncertain cases to a human.	A new task is added: reading the AI's reasoning on flagged cases and judging whether the model's judgment was right. A different skill with its own learning curve.	A rejection reason that is specific and actionable, so the customer knows exactly what to fix.
Address change is also a KYC (know-your-customer) and AML (anti-money-laundering) signal, so the governance design connects those events as one signal.	Capacity expectations, training, and override criteria are designed for that reality.	A realistic timeline when manual review is needed. Certainty built into the design.

Inside-out produces a faster process. It also produces an unmeasured information-security gap, an associate role that erodes under the load, and a customer left with status emails that say nothing useful. Triad design produces a faster process too, and it adds a defensible audit trail, an associate role that holds up, and a customer who feels the difference from the first touchpoint.

This is the framework at workflow altitude.

{/* V */}

V · Lens 1: Governance, compliance & risk Governance is the most underdesigned lens, and the one that decides whether the rest of the portfolio works.

Governance is consistently the most underdesigned element of enterprise AI transformation. Organisations know it matters. They just treat it as an oversight layer instead of a design input.

In rule-based automation, governance was bounded. In an AI world it becomes far more consequential: employees reach GenAI tools directly, large language models process customer data, and agentic systems act between human checkpoints rather than under sign-off at every step. In financial services the constraints are named and concrete. The EU AI Act classifies many of these workflows as high-risk. GDPR governs the customer data they touch. DORA sets the operational-resilience and third-party rules. Model-risk-management expectations, in the spirit of SR 11-7, require that an automated decision be documented and defensible.

These are not optional. They are hard limits on what the system can do, what data it touches, and how each decision is recorded.

In a regulated industry, these are non-negotiable constraints that must be in the room before the first workflow decision.

Missing governance produces slow, systemic damage. Projects multiply without coordination while vendors work in parallel with no visibility into each other; data gets handled inconsistently, security risk accumulates with no clear owner, and benefits are tracked differently across teams, or not at all. The organisation ends up with plenty of activity and no architecture.

The CoE is the architecture layer

The Centre of Excellence (CoE) is where a capability gets built once and reused everywhere. Without it, every team runs its own generator instead of plugging into one grid: every project rebuilds the same components from scratch, makes its own data decisions, and runs in a silo. The document AI built for address-change verification gets rebuilt for KYC onboarding, then for loan processing, then for claims. Three teams using three different vendors, each making its own call on how the same data is handled, with no visibility into which workflow depends on which capability.

A CoE designed for reusability changes this. One capability built once, governed once, and consumed across workflows. Dependencies are explicit. The portfolio is visible in one place. Broken, isolated solutions become streamlined, connected ones, because someone designed for that outcome from the start.

Governance as a design input means:

A CoE architecture built for reusability: capabilities consumed across workflows, dependencies visible, silos eliminated by design.
Compliance and information security in the design brief, not the review checklist.
GenAI access governance (which tools, on which data, with which oversight) owned as a governance decision from the start.
Benefit tracking that connects portfolio outputs to strategic goals.
Audit and escalation paths designed before deployment, while the system is still being built.

Before finalising any workflow, Lens 1 must answer:

What does this governance control require the ops team to do differently every day?
Does this structure make it harder or easier for the customer to get a resolution?
How will we know it's working at 30, 90, and 180 days, and who owns the signal?
Have we designed for AI-specific regulatory and information-security constraints, or only the old process ones?

{/* VI */}

VI · Lens 2: People & internal ops Adoption is a design problem treated as a communication one.

The most common mistake in transformation change management is treating adoption as a communication problem. Send the training. Run the workshops. Measure adoption at ninety days.

When AI surrounds a human role without redesigning it, the employee becomes the catch-all for everything the AI cannot handle. In rule-based automation, exceptions are predictable. With AI the exception landscape shifts: cases the model hasn't seen, outputs it got wrong, edge cases that need human judgment with no defined criteria. The human inherits the hard cases without the role redesign or training to handle them well.

Before any AI transformation is finalised, the people question must be answered at the workflow level. Which exceptions are handled by humans after this transformation, how complex are they, what is the cognitive load, and what does the training plan actually cover? The answer cannot be generic AI literacy. It is specific exception types, override criteria, and escalation paths.

The other failure mode is metrics. Organisations measure adoption at 90 days using the same KPIs as before. But the transformation changed what the work is. AHT goes down, which looks like success, while the cases left with humans are harder, error rates on exceptions climb, and employee satisfaction falls. The old metric reported a win that wasn't there.

Readiness is built during development, not announced at go-live

The most common change-management mistake is sequencing readiness after build. The app is developed in one stream. Training is scheduled in another. Go-live is the moment those streams are expected to meet. They rarely do, because the team has not had the time, exposure, or structured literacy to be genuinely ready for new ways of working.

The discipline that works is parallel readiness. While the app is being designed, the team is being brought along: AI-literacy programmes calibrated to the specific exception landscape they will face, exposure to model outputs before they have to act on them, structured familiarisation with the new metrics and override criteria. Readiness is verified before deployment. The gap between technical capability and human capability is closed before the system goes live.

I have seen the difference this makes. I architected a six-component agentic workflow for financial-crime investigation: orchestration, retrieval, judgment, verification, an audit log, and a human-review path. In that design, a judgment step scored each case against the policy criteria and a separate verification step checked that output against the source documents before any case was auto-approved. The pattern went into production with 120 specialist associates, cut handle time on the flagship workflow by 60%, and held 85%+ accuracy on false-positive case handling. The model was the straightforward part; what made it hold was the work around it: the associate's new role, the override criteria, and the audit path. Before go-live, the model was tested against a labelled set of real cases, and the errors it made there shaped where humans stayed in the loop. The 85% was checked against analyst-confirmed outcomes, not a model self-report.

This is also where the value of a multi-lens perspective becomes visible. A consultant or transformation lead who carries only the automation view will optimise the build. One who carries the governance, people, and customer lenses simultaneously will design the build, the readiness, the customer touchpoints, and the visibility architecture as one connected solution.

What actually works:

Exception workflow designed before go-live, not discovered after.
Cognitive load mapped against what the human actually has to manage in the new process.
Readiness built in parallel with development: AI literacy, model-output familiarisation, and override training delivered before go-live, not after.
New metrics built for the work the transformation actually created.
Gradual outcome ramp, building toward target performance over realistic timelines.
Literacy that addresses AI-specific uncertainty: when to trust, when to question, who's accountable.
Deliberate unlearning time before people are measured on new performance.

Before finalising any workflow, Lens 2 must answer:

Which exceptions land on the human, how complex are they, what is the cognitive load?
What is the training plan for those specific exceptions?
If the employee follows this new process perfectly, what does the customer experience?
Is the adoption metric still valid for the new process, or are we measuring the old world?

{/* VII */}

VII · Lens 3: Customer journey The outside-in starts here. The customer doesn't experience the transformation. They experience the outcome of it.

A transformation exists to serve an end customer, and the customer's experience is the only place its value actually shows up.

Three layers of customer understanding, not one

Most workflow redesigns operate at one level: the operational touchpoint. How does the customer experience this address change, this claim, this loan application? That level matters, but it is incomplete.

The Triad asks three layers of customer understanding before workflow redesign begins. First, who is this customer at segment and life-stage level? A relationship-banking client, where every interaction is a chance for proactive service, is not the same as a digital-first customer who wants zero human contact, or someone in the middle of a life event where the touchpoint signals something larger. Second, which product is in play? A mortgage, a savings account, and a wealth offering each make the same workflow land differently, and an optimisation that fits one can add operational burden to another. Third, does this process sit inside the product team's ownership, or does it need a separate operational team to run well? That last one is a structural design decision, and the Triad surfaces it early.

Without these three layers, operational redesign produces a workflow that is efficient but generic, treating every customer, product, and process as interchangeable.

When organisations redesign workflows for internal efficiency, they optimise for what they can measure internally: handle time, cost, processing speed, error rate. These metrics are valid. They don't map to what the customer experiences.

The IVR failure is a familiar pattern. A channel that is cheaper to operate is not automatically better to use. A self-service option that reduces agent load is not automatically one customers will choose, or choose again. Many organisations responded to IVR dissatisfaction by deploying AI chatbots, and repeated the same mistake at higher technical sophistication. The chatbot couldn't understand context, misread intent, looped customers through irrelevant flows.

The reason is the same in both cases: the channel was designed for operational efficiency. What resolution feels like from the customer's side never entered the design: certainty, clarity, minimal effort, a sense of being understood rather than processed.

Designing from the customer journey backwards means:

Starting with the customer's moment of truth: what does success feel like at the end?
Mapping the exception experience: the standard case usually works; the exception is where loyalty is won or lost.
Testing channel transitions: when customers move to a new channel, design that transition rather than assume it.
Designing AI interactions so the customer is understood and their issue actually resolved.
Measuring what the customer measures: resolution rate, effort, and certainty, alongside throughput.

Before finalising any workflow, Lens 3 must answer:

What does success feel like for the customer at the end, beyond what the dashboard shows?
Who owns the exception when this journey breaks down?
If the customer moves to a new channel, has the transition been designed?
What does customer success at 30 days look like, and how does it connect back to our KPIs?

{/* VIII */}

VIII · Measurement: the layer most frameworks skip The transformation changes what needs to be measured. Most measurement frameworks don't notice.

Most frameworks treat measurement as something you add at the end. The Triad treats it as a design question.

The old process had metrics that made sense for the old process. After AI transformation, the work is different and the customer interaction is different, but the measurement framework is often unchanged. Organisations measure the new process with instruments designed for the old one.

The result is false confidence. AHT drops while the human cases get harder and more error-prone. Call volume drops while digital-channel satisfaction sits unmeasured. Cost per transaction improves, and customer effort score was never tracked in the first place.

Three stages, one question at each

Baseline. Not just what we measure today, but whether those metrics reflect the health of this process, or just what has historically been easy to count.

Post-implementation. Are the same metrics still valid? What new signals has the AI process created: exception rates, model confidence, override frequency, drift, customer effort on new channels? Drift in particular needs an owner and a threshold that triggers re-evaluation, or it accumulates unseen.

Operational. Daily metrics built for the work the new process actually created. Each lens has its own signals, and those signals must validate each other. A governance metric that looks healthy while a customer metric is deteriorating is a warning sign that the lenses have drifted apart.

The central question across all three: are we measuring what matters in the new world, or what we could measure in the old one? {/* IX */}

IX · Cross-industry signals Which lens gets underweighted varies by sector. The failure rarely sits in the lens that got the investment.

The Triad applies wherever AI transformation meets operational complexity and human behaviour. The pattern of which lens is most commonly underweighted varies by sector.

BFSI

Governance is strongest. Customer journey is weakest: loan origination redesigned for compliance rather than for the applicant. People come next: fraud analysts reviewing a volume of AI alerts the role was never designed for.

Telecom

Customer journey is highly visible. The gaps are in people, where field engineers won't act on AI predictions they don't understand or trust, and in governance, where AI in customer service is deployed with no accountability design for handoff failures.

Retail & e-commerce

Customer-journey investment is high in acquisition. The gaps appear in operations: supply-chain AI that creates accountability vacuums when forecasts are wrong, and returns automation that fails visibly on the exception.

Manufacturing

Governance and technical investment are strong on the factory floor. The gap is in customer journey: AI improves production without connecting to order visibility, delivery reliability, or exception communication downstream.

The failure is rarely in the lens that received investment. It sits in the one or two that were treated as secondary.

{/* X */}

X · When all three hold A design discipline. Three perspectives in tension at every decision point.

The Triad is a design discipline. It means holding three perspectives in tension at every decision point, and slowing down when one of them is being ignored.

The organisations that do this consistently produce transformation that lands in the P&L, in employee performance data, and in customer satisfaction scores, all at the same time.

The ones that don't keep having the three conversations at the top of this article.

Design governance, operational reality, and customer experience as one system, or pay for the gap later in the P&L.

Prathyusha Vemula leads AI transformation and automation at Concentrix as Group Lead (Senior Manager); "Senior Consultant" is the formal HR designation. Her work spans agentic AI, GenAI, RPA, and Automation Centre-of-Excellence strategy across twelve years in BFSI, Telecom, FMCG, and Manufacturing. Her GenAI Agent Assist programmes run across 1000+ associates at three banking clients, and her automation work has delivered $5M in productivity gains over three years.

Tags · AI Transformation · Enterprise AI · Outside-In Triad · Governance · Compliance · Change Management · Customer Journey · Automation CoE · Agentic AI · Measurement

Revised v2 · May 2026 vemula.prathyusha@gmail.com