# Elevate with All > Thoughts, stories and ideas on agentic SaaS, customer success, and leadership - written by Sarabjeet Arora (Builder. Enabler. Leader) Public Ghost content for AI and LLM tooling. This file includes a bounded export of public pages first, then recent public posts. Append `.md` to any post or page URL to get the content in Markdown (for example, `/example-post.md`). ## Pages ### About this site URL: https://www.elevatewithall.com/about/ Last updated: 2026-07-31T20:46:24.000Z ## A Working Theory Elevate With All starts from a simple belief: growth that isn't shared isn't really growth — it's just relocation. This has roots in where I come from. Sikhism carries two ideas I return to often: *Sarbat da Bhala* — the wellbeing of all, not just your own — and *Chardi Kala*, a resilience that stays rising through setbacks, not around them. It's one life. Giving up was never on the table — just doing a little better than yesterday, over and over, until that's simply who you are. History tends to agree. Leaders who built *with* people are remembered with warmth long after the ones who just outran everyone else are forgotten. That's the pattern behind this name — not a slogan, a working theory: the people and ideas built to last were built together. ## Who's Behind This ![Sarabjeet Arora](https://storage.ghost.io/c/7a/f3/7af37721-b7fb-465b-980a-791cb1a6c4b3/content/images/2026/07/My-Linked-in-Image.jpg) [ **Sarabjeet Arora** ](https://www.linkedin.com/in/sarabjeetarora/?ref=elevatewithall.com) \- Business & Tech Executive with 20+ years enabling business outcomes through technology excellence. Multi-disciplinary experience spanning Customer Success, SaaS Transformation, Program Management, and People Leadership — 15 years in technology consulting with Capgemini across Fortune 500 verticals, followed by 4+ years driving cloud innovation with global ISVs at AWS. Thought leader by practice, not just title — ideating, writing, and speaking publicly, with most of that thinking published on LinkedIn. This site is where I share what that journey has taught me — and an open invitation to collaborate on business outcomes first, wherever agentic AI can genuinely move the needle ## What You Get Here #### **Talk tracks** — the business outcomes I write toward, with these as some of the ground I cover, not the limits of it: - **Agentic SaaS** — architecture, GTM, pricing, and the wider question of what agentic AI actually changes about how software gets built and sold - **Customer Success** — retention, growth, and the operating systems behind both - **Leadership** — what two decades of P&L, teams, and change management actually taught me - **Business Outcome Brainstorms** — open problems I don't have full answers to yet #### **What holds every piece to the same bar, regardless of topic:** - **Data-driven.** Claims are backed by real numbers or named sources — not vibes dressed up as insight. - **Problem → Solution → Benefit.** Every piece starts with a real, specific problem before proposing anything, and closes with what actually changes if you act on it. - **Real-world examples.** Grounded in something that actually happened, not a hypothetical dressed up as a case study. - **Built to internalize.** Deep enough to actually use — not a shallow take you forget by tomorrow. **Starting in 2027**, this site grows in two directions: featuring thinking from other senior leaders in my network, and opening a track on how agentic AI is showing up in everyday life — education, family logistics, daily decision-making — alongside the business-focused work above. ## Get Involved Elevate With All only works if what's here is genuinely useful — high bar, real value for readers. **Readers:** Connect on [LinkedIn](https://www.linkedin.com/in/sarabjeetarora/?ref=elevatewithall.com). Tell me what lands and what doesn't. Subscribe if this is worth your time regularly. **Contributors (2027+):** Senior leaders with something real to say — reach out on LinkedIn with your idea. ### Agentic Customer Success System- Account Team view URL: https://www.elevatewithall.com/agentic-customer-success-system/ Last updated: 2026-07-31T23:51:41.000Z _This page is for subscribers only._ ### Agentic Customer Success System- Leadership view URL: https://www.elevatewithall.com/agentic-customer-success-system-leadership-view/ Last updated: 2026-07-31T23:52:22.000Z _This page is for subscribers only._ ### Agentic Customer Success System- Product Management view URL: https://www.elevatewithall.com/agentic-customer-success-system-product-management-view/ Last updated: 2026-07-31T23:52:07.000Z _This page is for subscribers only._ ### Agentic Customer Success System- Product Marketing PLG URL: https://www.elevatewithall.com/agentic-customer-success-system-product-marketing-plg/ Last updated: 2026-07-31T23:52:53.000Z _This page is for subscribers only._ ### Agentic SaaS Business Architecture URL: https://www.elevatewithall.com/agentic-saas-business-architecture/ Last updated: 2026-10-13T00:06:38.000Z #### The complete series Most agentic AI projects don’t stall because the technology fails. They stall because the technology and the business were designed separately: an agent that works in the demo but has no market, no pricing logic, and no plan for the people it changes. This series designs them together. Five parts, in the order the decisions actually happen: > **Architecture → Go-to-market → Pricing → The people it touches** **Who it’s for:** SaaS and ISV founders, product leaders, CS and revenue leaders building or buying AI agents. **Time:** about 60 minutes in total, or one part a week. --- #### The series at a glance | | Question it answers | Key idea | | -------------------------------- | ------------------------------------------------ | ----------------------------------------------------------------------- | | **Part 1** · Blueprint | What does an agentic product need underneath it? | 7 layers, designed twice: once technically, once as a business | | **Part 2** · Go-to-market | Who buys it, and how do you sell it? | Value follows what the agent does on its own, not how many seats use it | | **Part 3** · Pricing | What do you charge for? | Five pricing tiers, from per-agent to per-outcome | | **Parts 4–5** · Connected Tissue | Who else does it affect? | Visibility before action, accountability after | --- #### Part 1 · The Blueprint [**Building Agentic SaaS: A Business Architecture Blueprint for Software That Thinks, Acts, and Scales →**](https://www.elevatewithall.com/building-agentic-saas-a-business-architecture-blueprint-for-software-that-thinks-acts-and-scales/) The foundation of the series: a seven-layer blueprint grouped into three stages (**THINKS, ACTS, SCALES**), with every technical layer paired to the business question it raises. Includes real-world failures at each layer and five questions to ask before your next sprint. *18 min read · Start here* #### Part 2 · Go-to-market [**Your Architecture Might Be Ready for Agentic SaaS. Is Your Go-to-Market? →**](https://www.elevatewithall.com/your-architecture-might-be-ready-for-agentic-saas-is-your-go-to-market/) Why traditional SaaS playbooks miss how agents create value. Covers market design (deployment architecture as segmentation, three buyers and three conversations), the go-to-market motion, and five leading indicators that show whether it’s working, with a diagnostic you can run. *13 min read* #### Part 3 · Pricing [**Your GTM Might Be Ready for Agentic SaaS. Is Your Pricing? →**](https://www.elevatewithall.com/your-gtm-might-be-ready-for-agentic-saas-is-your-pricing-2/) What to charge for, and why a pricing model can be mathematically right and still drive away your largest customers. The five-tier progression, choosing your metric, the “success tax”, migrating an existing customer base, and layered-cake pricing. *16 min read* > 💡 **Prefer shorter reads?** Part 3 is also available as two 7-minute pieces: > [How to Price an AI Agent,](https://www.elevatewithall.com/how-to-price-an-ai-agent-the-framework-for-what-to-charge-and-how-to-prove-it-part-1-of-2-2/) [Part 1: What to Charge and How to Prove It](https://www.elevatewithall.com/how-to-price-an-ai-agent-the-framework-for-what-to-charge-and-how-to-prove-it-part-1-of-2-2/) [Part 2: Why It Can Be Mathematically Right and Still Backfire](https://www.elevatewithall.com/how-to-price-an-ai-agent-why-it-can-be-mathematically-right-and-still-backfire-part-2-of-2/) #### Part 4 · The Connected Tissue (1 of 2) [**Who Else Gets Touched When You Deploy an Agent? →**](https://www.elevatewithall.com/the-connected-tissue-who-else-gets-touched-when-you-deploy-an-agent-1/) An agent changes more roles than the team that approved it. Maps the ripple effects across teams, the Replace / Assist / Compress spectrum, and why people need to see what an agent did before they act on it, not just afterwards. *7 min read* #### Part 5 · The Connected Tissue (2 of 2) [**Who Absorbs the Risk When an Agent Gets It Wrong? →**](https://www.elevatewithall.com/the-connected-tissue-who-else-gets-touched-when-you-deploy-an-agent-part-2/) Where agents shouldn’t go, why “the agent said it, not us” is no defence, and what rebuilds stakeholder trust after a failure. Closes the series with the questions every deployment team should ask. *7 min read* --- #### The frameworks in this series - **The 7-Layer Business Architecture:** THINKS (layers 1–3) · ACTS (4–5) · SCALES (6–7) - **The Pricing Tier Progression:** per agent → per input → per activity → per output → per outcome - **Layered-cake pricing:** stacking simple pricing methods instead of forcing one to do everything - **The Impact Spectrum:** Replace · Assist · Compress - **Value × Controlled Risk:** a stakeholder acceptance model for agent deployment ## Posts ### We Ask CSMs to Think Like Owners. Then We Pay Them Like Overhead. URL: https://www.elevatewithall.com/we-ask-csms-to-think-like-owners-then-we-pay-them-like-overhead/ Last updated: 2026-10-12T23:49:32.000Z CS 2030, Part 1 ### The mismatch nobody puts on a slide Let’s start with what we say out loud. We tell Customer Success Managers to own the customer. Protect the revenue. Grow the accounts. Act like business owners. And then? We pay them like overhead. A mostly fixed salary. A small bonus. And an annual rating, decided in a room they’re never invited into. I’ve spent two decades in SAP transformation programs at a global consulting firm and in ISV/SaaS customer work, and I keep running into the same pattern. We’ve rewritten what we expect from Customer Success. We haven’t rewritten how we organize it, measure it, or reward it. This series is my attempt to lay out what CS should look like by 2030, and it starts with that gap. ### The revenue already moved. The model did not. Here’s the quiet shift underneath all of this: in SaaS, the existing customer is now where most of the revenue comes from. In ChurnZero’s 2025 Customer Revenue Leadership Study, 74% of respondents said most of their revenue comes from existing customers. Pricing is following the money. With consumption and outcome-based models, customers pay as they get value. And when value delivered becomes revenue, the person closest to that value sits closest to the money. That person is usually the CSM. And yet most companies still run CS as a support function that happens to influence revenue, instead of a revenue function that happens to deliver support. Flip that sentence around and you get a very different function. ### Accountability without upside The public benchmarks make the gap hard to ignore: • **CS is measured on revenue.** Gainsight’s 2025 CS Index, covering 400+ companies, found that 93.7% of those measuring CS impact use a revenue target such as GRR or NRR. • **CS often owns the revenue moment.** ChurnZero’s studies of 1,000+ CS leaders show about half of CS teams own renewals, and about 40% own expansion. • **CS is not paid like it owns revenue.** In a Mostly Metrics compensation benchmark, most CSMs had 20% or less of their pay as variable. Only 5% had 40% or more, which is the split typically used for revenue owners. • **And the upside is shrinking.** ChurnZero found only 44% of CS teams were compensated for expansion in 2024, down from 57% in 2023\. Wrong direction. Now picture a single quarter. A CSM spots risk early and saves a $1M renewal. Down the hall, an account executive closes $1M in new business. The AE earns a commission. In most companies, the CSM earns a strong rating and hopes it shows up in next year’s raise. Same dollar. Very different thank-you. Here’s what that does. When pay stays the same whether a customer grows or churns, the system, not the person, is telling people that outcomes don’t matter. And people listen. What you get is compliance, not ownership. ### Ratings sustain. They don’t scale. Performance ratings were built for sustaining roles: deliver reliably, avoid mistakes, follow the process. Growth is a different job, and ratings struggle with it: • **They are relative.** A rating reflects your peers and the calibration room, not the customer value you created. • **They are capped.** Curves limit how many people can reach the top, no matter how much the business grew. • **They reward visibility** over quiet, compounding work like a renewal saved early. Nobody applauds the fire that never started. • **They favor caution.** With personal downside and capped upside, playing it safe is the rational move. Can you really blame anyone for making it? To be clear, ratings still have a place in development and behavior. But growth needs something different: a transparent, formula-based link between outcomes and income. ### What the research says about pay and performance • **A safety net plus upside works.** When Safelite Glass moved installers to pay per windshield, with an earnings floor so no one earned less, productivity rose 44% in six months. Half of that came from people putting in more effort, and half from who the model attracted. • **A mixed plan beats both extremes.** In a Fortune 500 sales force study, bonuses lifted productivity in every segment, and base salary plus commissions and bonuses was estimated to produce about 18% more revenue than pure commission. • **Pay design shapes who applies.** Economists call it sorting: pay that rises with results attracts results-driven people. It’s exactly why sales roles draw ambitious talent. • **Line of sight beats a pooled bucket.** Group incentives invite free-riding, and a pooled bonus spread through ratings weakens the link between what one person does and what they earn. • **Poor design gets gamed.** At one enterprise software vendor, an accelerating commission plan led salespeople to time deals with bigger discounts, costing 6% to 8% of revenue. Hand people a lever and they will find it. ### Two industries already walked this road **Healthcare: from paying for activity to paying for outcomes.** US healthcare long paid fee-for-service, billing for every visit and every procedure. Value-based care flips that and pays for outcomes and total cost. And it’s working: in 2024, Medicare’s Shared Savings Program saved $2.4 billion against benchmarks, its largest yet, and three in four of the 476 participating organizations earned shared savings. Patients came out ahead too, with fewer hospital stays and emergency visits, and better blood pressure and diabetes control. **Wealth management: from commissions to a share of client value.** Advisors once earned commissions on every product they sold. Most now earn a fee on assets managed, so their income grows only when the client stays and grows. In 2024, asset-based fees made up 72.4% of advisor compensation, and commissions fell to 23% of average revenue. Cerulli expects 77.6% of the industry to be fee-based by 2026\. Fee-based investors report higher satisfaction in J.D. Power’s Canadian research, and firms gained recurring revenue. It is the closest model I know for the commercial CSM. Three lessons carry straight over to CS: • **Change the incentive and behavior follows.** Providers invested in prevention. Advisors invested in long-term relationships. • **Outcomes must be measurable first,** or the models get gamed. • **Transitions need care.** Asked about a forced switch to fee-only accounts, almost 60% of commission-based investors told J.D. Power they would likely move firms. Phase the change in. Activity metrics and annual ratings are Customer Success’s fee-for-service. The commercial CSM, paid on the customer value they retain and grow, is our fee-based advisor. ### Why 2030 In my view, three forces converge by the end of the decade: • **Pricing:** consumption and outcome-based pricing keeps spreading, so revenue is earned as value is delivered. • **Agents:** AI takes over monitoring, low-touch renewals, and risk alerts, which changes how many customers one person can serve. • **Growth math:** with most revenue already coming from existing customers, retention and expansion decide growth and valuation. And 2030 is close enough to act on. A CS leader hired today can build toward it within their tenure. This is not a someday conversation. ### The CS 2030 thesis So here’s the thesis: run Customer Success as a revenue engine, built on three moves. 1\. **One owner for the existing customer.** Sales wins the customer; CS grows it. Part 2 digs into what that means for account management. 2\. **Paid on verified outcomes.** A secure base, plus individual, outcome-linked incentives with guardrails like value gates and clawbacks. 3\. **Scaled by agents.** Routine work moves to AI agents, so cost to serve falls as coverage grows. One catch. Outcome pay is only fair when targets reflect each account’s starting point. A CSM whose customer faces an acquisition or a shrinking market should not be judged like one whose customer is growing fast. Get that wrong, and CSMs will compete for the easy accounts instead of serving the hard ones. **From the CS 2030 toolkit:** This is why I use an **Account Propensity Index**. It scores every account on retention complexity (sponsor stability, competitive pressure, M&A or PE exit proximity) and expansion propensity (whitespace, the customer’s own growth, industry tailwinds) before any target is set. Look a little further out and, by 2035, strategic CSMs likely run something close to a customer P&L. Customers’ AI agents negotiate with vendors’ agents, with verified value as the shared language. ### What it delivers • **For customers:** one accountable relationship, no handoffs, and an advisor who gets paid when they succeed. • **For CSMs:** income that rises with impact, and a career path with real commercial ownership. • **For the company:** stronger retention and expansion, more predictable revenue, and a cost to serve that flexes with results instead of sitting there as fixed overhead. ### The CS 2030 operating model Here’s the honest part: fixing pay alone won’t get us there. The full model spans six dimensions, and this series takes them one at a time. ![Article content](https://media.licdn.com/dms/image/v2/D4D12AQGyrgchpz3gTQ/article-inline_image-shrink_1500_2232/B4DaEWrkGQGkAQ-/0/1791381881465?e=1793232000&v=beta&t=BAsGkSO352Qpd5XqIoNWGN1gdkeJ8nyLueD48PcGRkI) The CS 2030 operating model: six dimensions, eight themes ### Signals to watch: how to test this thesis A strategy should be testable. If CS 2030 is directionally right, these should keep moving: • **Ownership:** more CS teams owning renewals and expansion. • **Reporting lines:** more CS organizations reporting into a revenue leader. • **Pricing:** wider use of consumption and outcome-based pricing. • **Pay mix:** the variable share of CSM pay rising from today’s typical 20% or less. • **Line of sight:** more individual, book-based incentives, fewer pooled bonuses. • **Cost to serve:** revenue per CSM rising as agents absorb routine work, without retention falling. And if these stall or reverse? Then the thesis needs rethinking. I’d rather say that now than later. ### The CS 2030 Readiness Check Here are three questions from my CS 2030 toolkit. Try them on your own model, and be honest with yourself: 1\. What share of a CSM’s pay actually moves when a customer renews or churns? 2\. Does anyone on the team earn more when a customer grows? 3\. When a renewal is saved, who gets the credit, and how is it recognized? ### Coming in the CS 2030 series **Next, Part 2: Sales Wins the Customer. CS Grows It.** If the existing customer needs one owner, what happens to account management? I’ll make the case for ending the handoff and introduce the **Customer Ownership Model**. Planned for the rest of the series, each with a toolkit asset: Part 3: Ratings Sustain. Outcomes Scale. | Outcome-Linked Comp Blueprint Part 4: Cost to Serve Is a Design Choice | Cost-to-Serve Model Part 5: Verified Value: You Can’t Pay for Outcomes You Can’t Prove | Verified Value Ledger Part 6: Match the CSM to the Complexity, Not the Size | Competency-to-Complexity Matrix Part 7: The Human Edge Part 8: Trust by Design | Agent Accountability Framework Part 9: When Your Customer’s Agent Calls Your Agent ### Your turn If you lead or work in Customer Success, I’d love to hear from you. Does your pay reflect the revenue you are accountable for? And if you could change one thing about how CS is measured or rewarded, what would it be? Tell me in the comments. ### Sources • [ChurnZero 2025 Customer Revenue Leadership Study](https://info.churnzero.com/hubfs/2025%20CS%20Revenue%20Leadership%20Study.pdf?ref=elevatewithall.com) • [ChurnZero 2024 Customer Success Leadership Study key findings](https://churnzero.com/blog/2024-customer-success-leadership-study-key-findings/?ref=elevatewithall.com) • [Gainsight: What CS teams are prioritizing in 2026 (2025 CS Index)](https://www.gainsight.com/blog/what-customer-success-teams-are-prioritizing-in-2026-and-what-the-data-shows-is-working/?ref=elevatewithall.com) • [Mostly Metrics: The CS comp benchmarks](https://www.mostlymetrics.com/p/the-customer-success-benchmarks-you-ve-been-waiting-for?ref=elevatewithall.com) • [Lazear, Performance Pay and Productivity (American Economic Review, 2000)](https://www.gsb.stanford.edu/faculty-research/publications/performance-pay-productivity?ref=elevatewithall.com) • [Lazear, Incentives and Productivity (HKCER Letters, 2000)](https://hkcer.hku.hk/Letters/v61/lazear.htm?ref=elevatewithall.com) • [Chung, Steenburgh, Sudhir, Do Bonuses Enhance Sales Productivity? (Marketing Science, 2014)](https://hbswk.hbs.edu/item/first-look-august-20?ref=elevatewithall.com) • [NB Forum: Harvard study on sales compensation plans](https://www.nbforum.com/nbreport/harvard-study-finds-how-to-compensate-your-sales-people/?ref=elevatewithall.com) • [Larkin, The Cost of High-Powered Incentives (Journal of Labor Economics, 2014)](https://businessinnovation.berkeley.edu/wp-content/uploads/businessinnovation-archive/WilliamsonSeminar/larkin092106.pdf?ref=elevatewithall.com) • [Fierce Healthcare: Medicare ACOs saved $2.4B in 2024](https://www.fiercehealthcare.com/regulatory/mssp-acos-saved-24b-2024-setting-new-record-program?ref=elevatewithall.com) • [Becker's Payer: Medicare ACOs saved $2.4B in 2024](https://www.beckerspayer.com/payer/medicare-acos-saved-2-4b-in-2024/?ref=elevatewithall.com) • [Health Affairs: Medicare ACOs in 2024](https://www.healthaffairs.org/do/10.1377/forefront.20251105.540959/full/?ref=elevatewithall.com) • [InvestmentNews: Cerulli on fee-based advisor models](https://investmentnews.com/practice-management/more-than-three-quarters-of-advisors-to-embrace-fee-models-by-2026-cerulli-says/259740?ref=elevatewithall.com) • [J.D. Power 2015 Canadian Full Service Investor Satisfaction Study](https://canada.jdpower.com/node/671?ref=elevatewithall.com) • [Financial Planning: J.D. Power on commission clients and fee-only switch](https://financial-planning.com/news/fiduciary-changes-could-turn-clients-off-jd-power?ref=elevatewithall.com) *Several CS benchmarks cited come from CS platform vendors' surveys; I've used them for direction rather than precision. Views are my own.* ### Before You Automate: ROUTE - Deciding What Belongs on the AI Journey URL: https://www.elevatewithall.com/before-you-automate-route-deciding-what-belongs-on-the-ai-journey/ Last updated: 2026-10-12T23:39:56.000Z Part 3 of 4 - A Companion Framework \[Recap for readers arriving fresh: Part 1 laid out five fault lines behind 2026's enterprise AI measurement crisis and introduced CLEAR, a 5-phase loop for turning AI habit into governed capability. Part 2 operationalized it through mechanisms, quarterly cadence, and the balance sheet artifact. This piece asks a question that must be answered before any of that begins: does this process even belong on the CLEAR journey?\] ## The Question Everyone Skips Most AI adoption conversations start by asking what can be automated, completely skipping a harder and much earlier question: should this run on agentic AI at all, or does it belong somewhere else entirely? Gartner's own June 2025 prediction is the clearest warning available that skipping this question is expensive: over 40% of agentic AI projects will be canceled by the end of 2027, driven by escalating costs, unclear business value, or inadequate risk controls. ([Gartner Newsroom](https://www.gartner.com/en/newsroom/press-releases/2025-06-25-gartner-predicts-over-40-percent-of-agentic-ai-projects-will-be-canceled-by-end-of-2027?ref=elevatewithall.com)) Gartner also names the specific pattern behind a lot of that waste: "agent washing," where existing RPA bots and chatbots are rebranded as agentic AI without underlying capability, pushed by hype rather than real fit. The firm estimates only around 130 of the thousands of self-described agentic AI vendors offer genuine agentic capability. The necessary fix isn't adopting a posture of general caution toward AI; rather, it requires applying a disciplined decision framework before entering the Clarify phase, which I call ROUTE. ## ROUTE **R - RPA-Ready.** Rule-based, structured, stable inputs, high volume, and low judgment. The simplest version of this decision rule, borrowed directly from automation practitioners, states that if inputs are consistent and logic remains unchanged, the process stays on RPA ([Make, "RPA vs Agentic AI"](https://www.make.com/en/blog/RPA-vs-agentic-AI?ref=elevatewithall.com)). Existing RPA investments matter here too: ripping out a working, inexpensive, and deterministic bot to replace it with a probabilistic agent purely for an "AI-first" narrative is precisely the kind of misapplication Gartner's cancellation forecast warns against. **O - Orchestrate via Agentic AI.** High volume or high complexity, multi-step, cross-system, and judgmentlight, yet too dynamic or unstructured for a rules engine to handle over time, such as shifting approval logic, multiplying categories, or changing interfaces. This represents a genuine growth zone: Gartner projects that 33% of enterprise software applications will include agentic AI capability by 2028 (up from under 1% in 2024), and that 15% of day-to-day work decisions will be made autonomously through agentic AI by the same year (up from effectively zero in 2024). This is also the exact point where CLEAR from Part 1 takes over once a use case is routed here through Clarify, Launch, Embed, Amplify, and Review. **U - Upskill and Augment (Human-Assisted).** Moderate-to-high judgment, where AI drafts or recommends while a human makes the final decision. This is precisely the zone mapped out by the landmark Harvard Business School/BCG field experiment: AI-assisted consultants completed 12.2% more tasks, 25.1% faster, and at over 40% higher quality inside AI's capability range, but performed measurably worse outside it ([Harvard Business School AI Institute](https://aiinstitute.hbs.edu/back-tothe-beginnings-of-ai-at-work/?ref=elevatewithall.com)). The "jagged frontier" finding from that research functions as a direct routing instruction: augment where the frontier is favorable, and build in a mandatory human checkpoint precisely because workers cannot always discern in advance which side of the frontier a given task falls on. **T - Trust to Humans (Human-Dominated).** High-stakes, empathy-driven, exception-heavy, and possessing a low tolerance for error; a category every routing framework must protect explicitly, lest it be automated away by default momentum rather than deliberate decision. This pattern aligns with the National Institute of Standards and Technology (NIST) AI Risk Management Framework and its emphasis on human oversight for high-consequence decisions, ensuring automation speed never compromises diagnostic integrity, regulatory compliance, or human accountability. **E - Evaluate and Evolve.** Periodic re-routing as underlying models and organizational trust mature. Today's Trust-to-Humans category may become tomorrow's Upskill-and-Augment category as AI's jagged frontier smooths out in specific domains, while today's Upskill-and-Augment use case may eventually graduate to Orchestrate once the underlying judgment is well-enough understood to be encoded. This also closes ROUTE into a continuous loop shape identical to CLEAR, where Evaluation feeds back into a fresh routing decision rather than treating any initial categorization as permanent. ## A Practical Routing Check Before scoring a use case into CLEAR's Clarify phase, five questions decide which ROUTE category it belongs in first: **● Volume and repeatability:** does this occur often enough, and in a sufficiently similar shape, to justify automation at all? **● Structure and rule stability:** does the underlying logic shift constantly, or does it remain stable long enough for fixed rules to hold? **● Judgment and stakes:** does a failure carry costs that demand accountability a model cannot shoulder? **● Error tolerance:** can a failure happen silently and get caught downstream, or does an error propagate before anyone notices? **● Existing investment:** is there already a working RPA solution in place, and does replacing it deliver genuine value beyond a corporate narrative? A pattern of yes, yes, low, high, and yes points directly to RPA-Ready. A pattern of yes, no, low-to-moderate, moderate, and no points toward Orchestrate. High judgment with real stakes but clear efficiency upside points to Upskill-and-Augment. High judgment with real stakes alongside low error tolerance points straight to Trust-to-Humans, regardless of how easily automated the surrounding steps might appear. ## ROUTE in Practice Four quick walk-throughs help clarify how these categories resolve during an actual backlog review: **Invoice matching against a purchase order:** high volume, stable rules, low judgment; an RPA solution likely already exists. Routes to RPA-Ready. The temptation to upgrade this into an agentic workflow simply because agentic AI is currently trending represents the exact agent-washing pattern warned against by Gartner, as nothing here requires reasoning or fixing. **Triaging inbound customer health-score alerts across dozens of systems, with shifting categories and thresholds:** high volume, unstable rules, cross-system, moderate judgment. Routes to Orchestrate via Agentic AI, and enters CLEAR's Clarify phase as a genuine candidate. **Drafting a first-pass contract redline against a standard playbook**: moderate-to-high judgment, meaningful efficiency upside, but real financial and legal cost if a clause is missed. Routes to Upskill and Augment, where AI drafts, a lawyer decides, and the human checkpoint is the core value. **A performance or termination decision informed partly by AI-flagged productivity data:** high stakes, low error tolerance, real human consequence. Routes to **Trust to Humans**, full stop, regardless of how automatable the underlying data-gathering steps are. ## Where Routing Meets the Balance Sheet ROUTE does more than just dictate what to build; it establishes what standard of proof a use case owes, linking the framework directly back to the balance sheet artifact from Part 2\. An Orchestrate use case runs the full CLEAR loop and owes a validated outcome tied to a real baseline. An Upskill-and-Augment use case owes a lighter-touch quality and adoption signal rather than a full P&L line, given that the human decision-maker remains fully accountable. RPA-Ready processes continue reporting through existing operational metrics since they were never candidates for an AI P&L anyway, preventing unnecessary noise. That precise differentiation, ensuring not every routed use case owes the same kind of proof, is a design principle baked directly into the three-tier dashboard structure outlined in Part 2, where each function-level view tags a use case by category before determining the applicable accountability. ## What This Sets Up Three pieces in, one underlying argument: enterprises in 2026 are not struggling because AI fails to work; they are struggling because adoption outran the systems needed to route it, run it, and measure it. Part 1 named the five fault lines and introduced CLEAR as the loop for turning individual habit into governed capability. Part 2 made that loop operational through management mechanisms, a rapid enterprise cadence, and a balance sheet artifact giving CFOs visibility into capability rather than just costs. This piece adds the essential prerequisite decision: not everything belongs on that journey, and identifying the correct category beforehand separates the 5% of organizations BCG terms "future-built" from the 95% still trying to trace misplaced budgets. Naming categories and executing loops remains a theoretical exercise until given a concrete home. The balance sheet artifact from Part 2 is not hypothetical; it is a fully functioning prototype I have built featuring a board and portfolio view, a CFO ledger, and function-specific dashboards for Customer Success, Sales, and Engineering, all reconciled against a single shared data layer with every tracked use case tagged by its ROUTE category. Part 4 closes this series with a complete walkthrough of that dashboard, illustrating how CLEAR, ROUTE, and the balance sheet function together on screen rather than across separate articles. This is Part 3 of a 4-part series on measuring enterprise AI productivity. Parts 1 (the five fault lines and CLEAR) and 2 (mechanisms, cadence, and the balance sheet) are linked above; Part 4 (a full walkthrough of the AI ROI dashboard) is coming soon. ### Running CLEAR: Mechanisms, Cadence, and the AI Productivity Balance Sheet URL: https://www.elevatewithall.com/running-clear-mechanisms-cadence-and-the-ai-productivity-balance-sheet/ Last updated: 2026-10-12T23:31:34.000Z Part 2 of 4 - Operationalizing the Framework \[Recap line for readers arriving fresh: In Part 1, we laid out five fault lines behind 2026's enterprise AI measurement crisis and introduced CLEAR ( Clarify, Launch, Embed, Amplify, Review), a 5-phase loop for turning individual AI habit into governed organizational capability. This piece operationalizes it.\] ## Going Deeper: Tackling Fragmentation Layer by Layer The CLEAR loop runs at three altitudes simultaneously, and most enterprises only ever measure one of them. **Individual layer.** Habit formation, prompt literacy, and personal productivity proof points: the exact place where curiosity either becomes an owned habit or stays a side activity. Most organizations already track this; it's the layer every adoption dashboard covers. **Team layer.** Shared playbook libraries, team-level usage-to-outcome linkage, manager-led review cadence. This is where the real operational lever sits: Microsoft's research shows organizational factors like manager support and team culture account for roughly twice the measured AI impact of individual usage ([Microsoft WorkLab](https://www.microsoft.com/en-us/worklab/work-trend-index/agentshuman-agency-and-the-opportunity-for-every-organization?ref=elevatewithall.com)). Almost nobody measures it with the same rigor as the individual layer. **System/fabric layer.** AI embedded directly into the workflow itself: governance rails, cost-to-serve visibility, and read-back architecture that closes the loop from action to outcome. This is where most enterprises never arrive, which is exactly why KPMG finds only 7% report established ROI even as 79% call AI a top investment priority. The distinction that matters most here: **action counts are not validated outcomes.** Suggestions made or tasks created remain vanity metrics unless tied to a full lifecycle: suggested → reviewed → created → in progress → completed → outcome, where "outcome" means the targeted metric (churn risk, cycle time, pipeline velocity) actually moved over a 30, 60, or 90-day window. That requires read-back from the target system, not just write access. Very few organizations build this loop; the ones that do have a defensible efficacy story instead of an activity report, which provides the clearest way to answer the KPMG question when a CFO asks it. ## Mechanisms to Motivate, Harden, and Scale Adoption These concrete, operational levers directly address the failure modes documented in Part 1: **Hackathons and use-case sprints**. Held on a quarterly cadence to force artifact production over idea collection: a use case only counts if it can enter CLEAR's Launch phase with a real baseline attached. **Usage review rhythms.** Scheduled monthly at the team level and quarterly at the org level, where every review explicitly pairs usage data with outcome data. Usage alone is precisely what misled Uber: its own internal leaderboard ranked teams by token consumption, rewarding adoption without ever connecting it to shipped value. Any review that repeats that pattern repeats the mistake. **Drift observation.** Borrowed from model/data drift monitoring, this means watching for when team level adoption plateaus, reverts, or quietly diverges from the hardened playbook. Most adoption programs skip this because it requires admitting that early wins don't automatically stay wins. **Recognition and incentive design.** Reward validated outcomes rather than leaderboard position or raw usage, serving as the direct fix for the Uber pattern. Duolingo's own reversal is worth knowing here too: the company tied performance reviews to AI usage, then walked it back after employees noted the metric rewarded adoption for its own sake. **Champion and enablement network.** Team-level owners who translate org-wide playbooks into local context. A central playbook rarely survives contact with a specific team's actual accounts or workflows unmodified; a named champion per team adapts it rather than expecting a one-size-fits-all rollout to stick everywhere. ## The Quarterly Portfolio Cadence A full annual roadmap sounds tidy on a slide, but a fixed Q1-through-Q4 waterfall does not survive how fast this space moves; a plan written in January is stale by March. What holds up instead is a **rolling quarterly cadence**, where the organization always carries a live portfolio of use cases across every CLEAR phase at once: some in Clarify, some mid-Launch, some being Embedded, a few Amplifying, and a batch cycling through Review that feeds the next quarter's Clarify backlog. Every quarter runs the same review: not "did we hit the milestone," but "where does each use case sit right now, and what does it need to move forward?" The discipline that makes this work isn't the cadence itself; it is budget visibility across the pipeline stages. Most finance functions can report total AI spend for the quarter. Very few can answer the harder question: how much is committed to early-stage pilots versus hardened workflows versus ungoverned experimentation that hasn't even entered Clarify. KPMG's own Q2 2026 research found only 26% of organizations report full, real-time visibility into what their AI systems cost to operate. ([KPMG US, June 2026](https://kpmg.com/us/en/media/news/q2-ai-pulse-2026.html?ref=elevatewithall.com)) Without that visibility, a quarterly review is just a status meeting. That same visibility is what keeps governance and pace from fighting each other: it lets the organization move fast and know what it's spending at each stage, which is the real lesson underneath the Uber/Microsoft/Tesla caution from Part 1\. None of those companies lacked speed. They lacked stage-level visibility into what that speed was costing. ## The AI Productivity Balance Sheet & P&L The signature artifact, and the one most enterprises genuinely cannot produce today. **The P&L view** (in-year, expense-driven): token and license spend, cost-per-seat versus cost-per-active-user, hours reclaimed or cost avoided this quarter. Nearly every organization can produce this slide, as it is the one finance already asks for. **The balance sheet view** (cumulative, capability-driven): number of use cases that made it through Launch's validation gate and got hardened into playbooks, percentage of workflows with true system layer embedding, and where the organization sits on a capability maturity curve year over year. Almost nobody produces this one. KPMG's own data makes the case for why this distinction matters more than it sounds like it should: organizations with full visibility into their AI operating costs are five times more likely to report established ROI than those without (15% versus 3%). ([KPMG.com](https://kpmg.com/xx/en/media/press-releases/2026/06/growing-adoption-signals-progress-as-cost-visibility-and-accountability-drive-ai-value.html?ref=elevatewithall.com)) Visibility isn't a nice-to-have layered on top of the spend; it represents the difference between the large majority of organizations still guessing and the small minority that can actually defend their number to a board. **What goes into building this artifact is harder than the two-view summary suggests.** A few design decisions matter enough to name, because most first attempts at an AI P&L trip over exactly these: ● **The numbers must reconcile top-down and bottom-up, or the artifact is disqualified in front of a CFO.** If a board view and a function's own dashboard add up to different totals for the same spend, the mismatch becomes the story. The fix is one shared data layer every view reads from, rather than each layer asserting its own figures. ● **Attribution must separate AI's share from everything else that could explain the same result.** A metric moving after an AI rollout isn't proof AI caused it, because pricing, seasonality, and headcount shifts move metrics too. A defensible P&L needs a contribution-mix view: AI's estimated causal share, named concurrent factors, and an honest residual. ● **Funding source and workforce impact belong at the function level, not asserted from above.** Only the team running a use case knows whether it displaced a tool, added net-new budget, or avoided a hire. ● **A confidence tier belongs on every reported figure.** Customer-confirmed, benchmark-modeled, and reasoned-estimate are not the same evidentiary weight, and collapsing them into one number erodes trust the first time someone asks "how do you know." ● **A shadow AI rollup and a forward-looking run-rate belong on the same page as realized value;** otherwise, the artifact reports what happened without flagging what's about to happen. Building this properly is a genuinely different exercise from building a usage dashboard, which is why so few organizations get past the P&L view. I've been building a working prototype of this system: a threetier structure running from a board/portfolio view down to a CFO ledger down to function-specific dashboards for Customer Success, Sales, and Engineering, all reading from one reconciled data layer. ## Close Productivity becomes an organizational capability only when it's measured, governed, and compounded, not when it's merely adopted. The mechanisms, cadence, and balance sheet artifact in this piece are what make CLEAR something an organization actually runs, quarter over quarter, rather than a framework that looks good on one slide and never gets revisited. One question remains open, and it's worth asking before any of this gets applied broadly: not every process belongs on the CLEAR journey in the first place. Some are better left to existing RPA, some genuinely need to stay human-led, and getting that call wrong upstream undermines everything downstream. That's Part 3: a companion framework called ROUTE. The dashboard prototype described above gets its own full walkthrough later in this series, once ROUTE has established which use cases actually belong on it. This is Part 2 of a 4-part series on measuring enterprise AI productivity. Part 1 (the five fault lines and the CLEAR framework) is linked above; Part 3 (ROUTE: deciding what to automate, and how) and Part 4 (a walkthrough of the AI ROI dashboard) are coming soon. ### Licenses Aren't Leverage: Why Enterprise AI Productivity Still Can't Be Measured URL: https://www.elevatewithall.com/licenses-arent-leverage-why-enterprise-ai-productivity-still-cant-be-measured/ Last updated: 2026-10-12T23:32:02.000Z Part 1 of 4 - Diagnosis and the CLEAR Framework ## Why This, Why Now Somewhere between the town-hall slide claiming "AI-first" and the Q3 budget review asking where the money went, most enterprises hit the same wall in 2026\. Uber burned through its entire annual AI coding budget by April, hitting that ceiling roughly four months in. The rollout itself was a success by every adoption metric: approximately 5,000 engineers onboarded, 84% classified as agentic-coding users, nearly 70% of code commits AI-generated. And yet the company's own COO, Andrew Macdonald, said publicly that his team can't yet draw a line between rising token usage and shipping "25% more useful consumer features." ([Fortune, May 26, 2026](https://fortune.com/2026/05/26/uber-coo-ai-spending-tokens-claude-code/?ref=elevatewithall.com)) Microsoft began cancelling Claude Code licenses across its Experiences + Devices division by June 30\. ([Windows Central, citing The Verge](https://www.windowscentral.com/microsoft/microsoft-cancels-claude-code-licenses-shifting-developers-to-github-copilot-cli-a-move-likely-driven-by-financial-motives?ref=elevatewithall.com)) Tesla capped engineer AI spend at $200 a week starting July 6, and Walmart capped usage of its internal coding assistant. ([Electrek, July 2, 2026](https://electrek.co/2026/07/02/tesla-caps-employee-ai-spending-200-week/?ref=elevatewithall.com)) None of these are companies that failed to adopt AI. They're companies that adopted it faster than they built the ability to measure what it was doing for them. This isn't a narrative about AI failing to work; rather, it marks the end of the easy adoption phase. For two years, the enterprise playbook was simple: get people using it, count the seats, celebrate the percentage. That phase is over. What replaces it is far less photogenic and significantly harder: the strict discipline of knowing, backed by concrete evidence, whether AI usage is turning into a genuine organizational capability or remaining an expensive habit. That is the exact question this piece aims to answer practically. The debate over whether to invest in AI productivity is finished; the real challenge now lies in measuring it accurately so that this year's spend compounds into next year's capability instead of resetting to zero every January. ## The Problem, Fully Qualified Strip away the vendor slides and five fault lines show up consistently across 2026's enterprise data, ranked here by how much damage each is doing right now, not alphabetically. **1\. The Spend-Governance Breakdown.** Token-based consumption pricing broke the per-seat budgeting model finance teams have run on for decades. Gartner's own forecast puts worldwide AI agent software spend at $206.5 billion in 2026, up from $86.4 billion in 2025; a 139% jump in a single year. ([Gartner Newsroom, May 2026)](https://www.gartner.com/en/newsroom/press-releases/2026-05-05-gartner-says-autonomous-business-and-artificial-intelligence-layoffs-may-create-budget-room-but-do-not-deliver-returns?ref=elevatewithall.com) You can't govern what you can't forecast, and most finance functions are still building that muscle. **2\. The Data Foundation Gap.** Before any measurement conversation is possible, the data has to be trustworthy. Multiple 2026 enterprise surveys put data quality/readiness at or near the top of cited barriers to AI value, ahead of model capability or compute cost. Everything downstream - ROI attribution, outcome tracking, governance is speculation if this layer isn't solid. **3\. The Measurement & Attribution Gap.** Even with clean data, most enterprises can't agree internally on what "success" means. DoiT's February 2026 survey of 500 Finance leaders (Sapio Research) found only 15% can calculate AI ROI without significant bottlenecks; the top-cited barrier, ahead of the pace of technology change itself, is that Finance and Engineering define AI success differently (37% overall, 43% of the C-suite). ([DoiT / Sapio Research)](https://www.doit.com/blog/ai-spending-survey?ref=elevatewithall.com) The downstream effect: MIT's own NANDA report - The GenAI Divide: State of AI in Business 2025, based on 300 deployment reviews, 52 executive interviews, and 153 leader surveys, found 95% of GenAI pilots produced no measurable P&L impact. ([MIT NANDA, full report](https://mlq.ai/media/quarterly%5Fdecks/v0.1%5FState%5Fof%5FAI%5Fin%5FBusiness%5F2025%5FReport.pdf?ref=elevatewithall.com)) KPMG's own Q2 2026 Global AI Pulse (2,145 leaders, 20 countries) is the starkest summary: AI remains a top investment priority for 79% of leaders, average spend holds around $188 million, and only 7% report having established ROI from it at all. [(KPMG press release, June 24, 2026)](https://kpmg.com/xx/en/media/press-releases/2026/06/growing-adoption-signals-progress-as-cost-visibility-and-accountability-drive-ai-value.html?ref=elevatewithall.com) **4\. Individual-to-Organization Fragmentation.** This is the one most articles skip, and it's the thesis of this piece: individual productivity is not the same thing as organizational capability, and most enterprises are quietly conflating the two. Gallup's own July 2026 release, drawing on its ongoing US workforce panel, found 52% now use AI at work at least a few times a year, but only 15% use it daily, with much of that usage still informal. ([Gallup.com, July 2026](https://www.gallup.com/workplace/712736/organizational-adoption-jumps-six-points.aspx?ref=elevatewithall.com)) Microsoft's own 2026 Work Trend Index (20,000 knowledge workers, 10 countries, fielded with Edelman Data x Intelligence) found only 16% of AI users qualify as "Frontier Professionals" who've actually redesigned their work around AI, and that organizational factors like culture and manager support account for roughly twice the impact of individual usage. ([Microsoft WorkLab, official report](https://www.microsoft.com/en-us/worklab/work-trend-index/agents-human-agency-and-the-opportunity-for-every-organization?ref=elevatewithall.com)) Fyxer's 2026 Admin Burden Index (2,000 US office workers, commissioned via OnePoll) found that while 88% now use AI, only one in four say it's fundamentally changed how they work, and workers using AI embedded directly into their workflow were 63 percentage points more productive than those using standalone tools. ([Fyxer, official report](https://www.fyxer.com/blog/ai-productivity-trap-report?ref=elevatewithall.com)) The sharpest single number comes from WRITER's own 2026 enterprise survey: 97% of executives report benefiting from AI personally, but only 29% see significant organizational ROI. ([WRITER, official report](https://writer.com/blog/enterprise-ai-adoption-2026/?ref=elevatewithall.com)) That 68-point gap between "it helped me" and "it helped us" is the whole problem in one statistic. **5\. Shadow AI & Governance Sprawl.** The first four fault lines compound into a fifth: ungoverned usage itself becomes a cost and risk multiplier. Shadow AI employees using unauthorized tools with company data shows up repeatedly in 2026 industry survey data as affecting roughly two-thirds of enterprises, creating duplicate spend on top of fault line one, plus real compliance exposure. Deloitte's own State of AI in the Enterprise 2026 report names insufficient worker skills as the top-cited barrier, with data privacy/security concerns close behind at 73%. ([Deloitte Global, official report page](https://www.deloitte.com/global/en/issues/generative-ai/state-of-ai-in-enterprise.html?ref=elevatewithall.com)) Contentstack's 2026 Agentic Enterprise Report found integration difficulty (37%) and governance/security concerns (34%) are the two most-cited barriers to scaling agentic AI specifically, well ahead of the inability to prove ROI (24%), suggesting governance is the bottleneck before measurement even becomes the constraint. ([Contentstack, official report](https://www.contentstack.com/resources/report/agentic-enterprise-report-2026?ref=elevatewithall.com)) Put the five together, and the picture is uncomfortably clear. Enterprises aren't failing to adopt AI. They're failing to convert curiosity into individual habit, individual habit into team capability, and team capability into something the organization can actually govern, measure, and compound year over year while shadow usage quietly makes the spend problem worse in the background. Thousands of licenses procured. A genuine surge in individual output. And still, when the CFO asks "so what did we get for it," most organizations don't have an answer that survives an audit. ## What Executives Actually Want To make real sense of performance, productivity must be translated out of CS and HR jargon and mapped directly to the four core metrics that executive leadership monitors: ● Productivity → cycle-time and throughput per FTE-equivalent, not raw usage volume ● Profitability → margin contribution and cost-per-outcome versus cost-per-seat, the distinction KPMG's data shows separates the 7% with established ROI from everyone else ● Revenue growth → pipeline velocity, win-rate lift, expansion movement that can actually be attributed to an AI-assisted workflow, not just correlated with one ● Acceleration → speed-to-capability and the ability to redeploy freed capacity into net-new value, not headcount reduction as the only story The underlying tension weighing on executives is straightforward: they need a true balance sheet view tracking the cumulative capabilities built and owned by the company, rather than just a P&L register of quarterly expenses. Uber's COO put it plainly when he described the core trade-off as token consumption versus headcount; a balance sheet question dressed up as a spending line. Most organizations today can produce the P&L slide. Almost none can produce the balance sheet. That gap is exactly what a later piece in this series is built to close. ## Solution Approach - The CLEAR Framework None of the major consulting frameworks published in 2026 solves scaling on their own; they diagnose why enterprises are stuck, which is a different job. BCG's own research, based on a 2025 survey of 1,250 senior executives, distills into what the firm calls the 10-20-70 rule: only about 10% of AI value depends on algorithms, 20% on technology and data infrastructure, and a full 70% on people and process redesign. ([BCG.com, 2026](https://www.bcg.com/publications/2026/ai-transformation-is-a-workforce-transformation?ref=elevatewithall.com)) McKinsey's own Rewired playbook makes a parallel case, organizing successful tech-and-AI transformation around six capabilities spanning strategy, talent, operating model, technology, data, and, critically, the one most enterprises skip: adoption and scaling. ([McKinsey.com](https://www.mckinsey.com/capabilities/tech-and-ai/our-insights/the-ai-transformation-manifesto?ref=elevatewithall.com)) And the landmark Harvard Business School/BCG field experiment with 758 consultants, now peer-reviewed and published in Organization Science found AIassisted consultants completed 12.2% more tasks, 25.1% faster, at over 40% higher quality inside AI's capability range, but were measurably worse on tasks outside it. The researchers called this the "jagged frontier": AI doesn't uniformly raise capability, and blanket rollouts that ignore where that frontier sits are exactly what fragment productivity instead of compounding it. [(Harvard Business School AI Institute)](https://aiinstitute.hbs.edu/back-to-the-beginnings-of-ai-at-work/?ref=elevatewithall.com) Ultimately, the evidence converges on a single conclusion: the primary constraint is not the underlying model, but the supporting organizational system. This realization led to the creation of CLEAR, structured as a continuous 5-phase operational loop: **C - Clarify.** Align on goals and prioritize the backlog. Tie every use case to a named executive metric: margin, cycle time, NRR before any tooling conversation starts. Score candidates against impact × feasibility × data-readiness, not against who asked loudest. **L - Launch.** Run a bounded pilot with a real baseline captured up front. A quality/validation gate sits inside this phase: an explicit go/no-go/kill call, not a default extension because nobody wants to say a pilot failed. **E - Embed.** Adopt at team level with a named owner, then harden into a reusable playbook. Usage gets tied to outcome tracking from day one, not treated as a separate measurement project bolted on later. **A - Amplify.** Scale to the system/workflow fabric layer so the capability survives past any one champion or team. This is where individual habit becomes organizational muscle memory. **R - Review.** Govern cost-to-value, monitor for drift, measure outcomes against the original baseline then loop back into Clarify for the next cycle. ## Where This Goes Next The CLEAR framework provides structural form, but a methodology proves its worth only in execution. Putting it into practice immediately surfaces three critical questions that this piece purposely leaves open for deeper exploration: How do you motivate teams to surface their best use cases and maintain their operational rigor rather than letting them slip back into isolated, one-off habits? Furthermore, how can an organization maintain a dynamic portfolio of initiatives moving concurrently through Clarify, Launch, Embed, and Amplify, especially in a market moving too fast for traditional annual planning without losing track of expenditures at every phase? Finally, what does the exact executive artifact look like that finally gives a CFO clear visibility into accumulated enterprise capability rather than just quarterly software costs? Those three questions form the exact starting point for Part 2 of this series. The upcoming installment covers the specific mechanisms required to turn individual habits into team muscle memory, establishes a quarterly cadence calibrated to the speed of modern markets, and introduces the AI Productivity Balance Sheet & P&L that most enterprises struggle to generate. Part 3 takes a step back to a related but distinct question: which processes belong on this journey at all, versus staying RPA, staying humanassisted, or staying fully human under a companion framework called **ROUTE**. Part 4 closes the series with a walkthrough of that balance sheet as a working artifact, not just a description of one. This is Part 1 of a 4-part series on measuring enterprise AI productivity. Part 2 (mechanisms, quarterly cadence, and the balance sheet artifact), Part 3 (ROUTE), and Part 4 (a walkthrough of the AI ROI dashboard itself) are coming soon. ### How to Price an AI Agent: Why it can be Mathematically Right and still Backfire (Part 2 of 2) URL: https://www.elevatewithall.com/how-to-price-an-ai-agent-why-it-can-be-mathematically-right-and-still-backfire-part-2-of-2/ Last updated: 2026-10-12T07:06:32.000Z Let's start with a scenario I keep seeing pitched, one that looks perfect on a spreadsheet: a risk-auditing platform charges customers a percentage of the risk value it identifies and prevents. The bigger the enterprise, the greater the exposure, the greater the value prevented, and, naturally, the greater the fee. Value-aligned pricing. Textbook value-based design. It's also the kind of pricing model that can quietly open the door for a competitor to walk into your largest accounts, not by being better, but by being simpler. We'll come back to that. It's one of the sharpest examples I've seen of a problem that runs through almost every pricing conversation I have with ISVs: the math can be spot-on, while the underlying psychology is completely off base. Before we get to why, there's a more fundamental question most teams skip entirely: **What are you actually charging for?** ### The Tier Progression: From Per-Input to Per-Outcome In the architecture piece, I wrote about seven layers that have to be designed together. Pricing isn't an eighth layer added afterwards; it's a lens across all seven, and it tends to follow a progression as products mature. I think about it as five tiers, each answering the same question differently: **what does the customer actually pay for?** 1) **Per Agent.** The customer pays per deployed agent or seat served. Familiar, easy to budget, easy to sell. For the vendor, it's also the most predictable revenue line in the model; headcount is stable, contracts renew annually, and forecasting doesn't swing with usage the way activity- or outcome-based revenue does. But the value of an agent doing more autonomous work doesn't show up in the agent count, so pricing and value begin pointing in different directions, the same disconnect I described in the GTM piece. This is where the model most often backfires. [Microsoft and Google both tried flat, per-seat pricing for their AI assistants - Copilot and Gemini at $20–30 per employee per month, and ran into real customer resistance](https://www.axios.com/2025/01/21/microsoft-google-price-hikes-ai-chatbots?ref=elevatewithall.com): value varied sharply by role. For example, a developer might use it daily, an administrator barely at all, yet every seat carried the same flat fee, and a per-seat add-on for a workforce of thousands is hard to defend internally without a clear line from cost to realized value. Per-agent pricing needs either a defined scope ceiling or a visible usage signal attached to it, or it reads as a tax on headcount rather than a price on work. For example, Claude's own consumer subscriptions work this way in practice: a flat monthly fee paired with a rolling usage window that Anthropic tightens or loosens as demand and available compute shift. It was tightened in August 2025 under heavy load, doubled again in May 2026 once new capacity came online. The ceiling isn't a flaw in the pricing; it's the mechanism that keeps a flat fee sustainable against a cost base that moves. 2) **Per Input.** The customer pays for what they put in: API calls, tokens, documents processed. Easiest to implement, weakest signal; it charges for effort rather than results. For the vendor, it's also the weakest pricing power in the entire progression: you're monetizing at the cost layer, easy for a competitor to beat on price alone since there's nothing to differentiate on but the rate. The token-metered version of this carries an odd penalty on top: a smarter agent that solves the same task in fewer tokens earns the vendor less, even though call volume (how often the customer actually needs the agent) doesn't shrink just because the model got more efficient. [OpenAI's API is priced this way, per million tokens processed](https://www.g2.com/articles/openai-api-pricing?ref=elevatewithall.com), regardless of whether the output was useful; the classic foundation-model metric most agentic vendors build on top of, then move away from as they climb the tiers below. An agent that takes ten attempts costs the customer ten times more than one that gets it right the first time. That completely misses the point. 3) **Per Activity.** The customer pays per task, transaction, or workflow completed, such as a ticket resolved or a claim adjudicated. This ties price to work customers recognize as getting done, not infrastructure consumed. For the vendor, revenue now scales with actual usage instead of being capped at a flat fee, which keeps growth incentives aligned with the customers, but it requires real metering infrastructure to track reliably, and it can quietly reward maximizing the number of billable activities over the quality of each one. [Document processing vendors like Hyperscience and Rossum charge roughly $1.50 per page processed,](https://www.opticintellect.com/compare/hyperscience-vs-rossum-ai?ref=elevatewithall.com) a clean per-activity metric where the unit is the task itself, not the outcome the task eventually produces. 4) **Per Output.** The customer pays for the deliverable produced: a report, a design, a drafted contract, regardless of how many attempts it took. For the vendor, this shifts technical efficiency risk onto you as you absorb the cost of every failed attempt, not just the one that ships, so your margin depends on how efficiently your agent gets to a usable result. For the customer, it's a stronger value signal: they are paying for what they keep, not what they tried. [AdCreative.ai prices this way for ad creatives: generation itself is unlimited, and a credit is only spent when the customer downloads a finished creative.](https://aiblogfirst.com/adcreative-ai-pricing/?ref=elevatewithall.com) 5) **Per Outcome.** The customer pays for the business result itself: revenue protected, costs avoided, risk prevented. Some of the most attractive economics in agentic SaaS live here, because price scales with value delivered rather than effort or volume. [Chargeflow, an AI chargeback-recovery platform, charges 25% of each disputed payment it wins back and nothing if it loses,](https://www.chargeflow.io/pricing?ref=elevatewithall.com) a clean, real example of the model: no recovery, no fee. For the vendor, it's also the tier that demands the most maturity: you can't charge for an outcome you can't reliably measure and attribute, and unlike every tier before it, the burden of proving causality, not just correlation, sits entirely on your side of the table. ![Article content](https://media.licdn.com/dms/image/v2/D5612AQG10RjjYvifyA/article-inline_image-shrink_1500_2232/B56aAVJHXdGsAU-/0/1787061106813?e=1793232000&v=beta&t=Y9Mvm0SZ6gIekLpMNqfSBefmsptnxujIA-XZeC9XMUY) The Tier Progression **Choosing Your Metric: The COMPASS Framework** The five-tier progression tells you what the options are. It doesn't tell you which fits your product. For that, I'd point to [COMPASS](https://aws.amazon.com/isv/resources/why-saas-companies-must-transform-for-agentic-ai/?ref=elevatewithall.com) (Choice of Optimal Metrics for Pricing Agentic Systems & Solutions), developed by Michael Mansard and published in a joint AWS, Zuora, and Simon-Kucher whitepaper on agentic AI pricing. COMPASS asks two questions. First, what's the scope of work: narrow tasks like a factory-line worker, a multi-step process like a service, or an open-ended goal like a partner? Second, how attributable is the impact? Can you trace a result directly to what the agent did, or is it mixed with other factors? Plot your product on those two dimensions, and you get a strong signal for where you can credibly operate on the tier progression. A narrow-scope agent with diffuse attribution belongs closer to per-input or per-activity; claiming per-outcome pricing there is hard to defend to a sophisticated buyer and hard to measure yourself. Broad-scope agents pursuing measurable goals sit at the other end where outcome pricing becomes credible, economically attractive, and, by extension, where premium pricing becomes possible. Broad scope combined with high attribution creates a metric competitors struggle to replicate convincingly. ![Article content](https://media.licdn.com/dms/image/v2/D5612AQG0LLlLFKuwzw/article-inline_image-shrink_1000_1488/B56aAUs.GDGsAI-/0/1787053728631?e=1793232000&v=beta&t=h_4lkzZ_KTGEe_zaQEnZCQtEtDrgP5m55Lh4bKyiRUA) The COMPASS Framework This is where the example from the architecture piece becomes relevant again. [Intercom's Fin support agent moved to outcome-based pricing by charging per resolution and reported net revenue retention climbing from 112% to 146%.](https://www.mostlymetrics.com/p/how-intercom-reaccelerated-growth-with-outcomebased-pricing?ref=elevatewithall.com) That's not a coincidence; resolution is a high-attribution, well-scoped outcome, exactly the COMPASS sweet spot. The framework's own framing makes this point directly; pricing metrics are often the first thing teams focus on, but they're only one piece of the strategy. In agentic AI, pricing and packaging aren't downstream of go-to-market; they're part of the foundation the rest of the motion gets built on. **Value Measurement and Aligned Reporting** Choosing a high-attribution metric only holds up if the measurement behind it holds up too, and this is where most of the gap actually lives. A [Gartner survey found 31% of chief sales officers cite proving the ROI of AI-driven tools as a top challenge to their 2026 objectives,](https://www.gartner.com/en/newsroom/press-releases/2026-05-19-gartner-survey-showsthirty-one-percent-of-chief-sales-officers-cited-difficulty-proving-roi-of-ai-driven-tools-as-atop-challenge-for-sales-objectives-in-two-thousand-twenty-si?ref=elevatewithall.com) and [IBM's Institute for Business Value found only 25% of AI initiatives have delivered their expected ROI.](https://newsroom.ibm.com/2025-05-06-ibm-study-ceos-double-down-on-ai-whilenavigating-enterprise-hurdles?ref=elevatewithall.com) The gap isn't uniform: [Microsoft-sponsored IDC research puts the average return at $3.70 per dollar invested, with top-performing, well-measured organizations reaching $10.30](https://news.microsoft.com/en-xm/2025/01/14/generativeai-delivering-substantial-roi-to-businesses-integrating-the-technology-across-operationsmicrosoft-sponsored-idc-report/?ref=elevatewithall.com); measurement rigor is a large part of what separates the two. Three practices close that gap. 1\. **Capture a pre-agent baseline before go-live;** you simply can't prove lift retroactively. 2\. **Build customer read-back access into the contract** rather than retrofitting it at renewal, when the ask looks defensive. 3\. **Publish the methodology itself,** not just the number, so the customer can audit it rather than take it on faith. Reporting cadence matters as much as methodology. A recurring business review that shows the customer the same number you're billing against turns the invoice into a confirmation of something they already saw coming, not a sudden surprise. So far, that's the foundation: what you actually charge for, the test for which tier you can credibly hold, and the measurement discipline that keeps a high-attribution metric honest. Everything harder gets built on top of it: how you package the metric, what earns you the right to charge a premium, and why an outcome-based model that scores perfectly on every framework here can still quietly cost you your largest accounts. That last one is the risk auditing example I opened with, and Part 2 is where I come back to exactly why it breaks. ### The Connected Tissue: Who Else Gets Touched When You Deploy an Agent? (Part 2 of 2) URL: https://www.elevatewithall.com/the-connected-tissue-who-else-gets-touched-when-you-deploy-an-agent-part-2/ Last updated: 2026-10-12T06:54:22.000Z Part 1 mapped who gets touched when you deploy an agent: the four teams a single Customer Success agent quietly makes load-bearing, and the way one misjudged classification compounds down a chain before anyone can question it. This half is about the edges of that map: the decisions agents shouldn't make, the ways an agent can speak in your name and get it wrong, and what actually rebuilds trust once it's shaken. Start with the edges. ## Where Agents Shouldn't Go, and the Autonomy Trade Underneath It Some domains carry a downside that no efficiency gain justifies legal, financial, and brand-risk decisions where a rare failure costs more than the aggregate savings are worth. In February 2024, a BC tribunal found Air Canada liable for its chatbot's incorrect advice on bereavement fares. ([CBC News](https://www.cbc.ca/news/canada/british-columbia/air-canada-chatbot-lawsuit-1.7116416?ref=elevatewithall.com)) Air Canada's defense that the chatbot was a "separate legal entity" not responsible for its own words was explicitly rejected. The airline was ordered to honor the fare the bot promised. The ruling that matters here isn't the dollar amount; it's that "the agent said it, not us" isn't a defense anywhere a court, a regulator, or a customer is involved. This is really a question about the autonomy trade, made concrete. Human-in-the-loop keeps a named person accountable for the call and measurably reduces the failure modes above, but there's a legitimate case for full autonomy too, on speed, scale, and cost, and the honest framing isn't that autonomy is wrong. It's that autonomy removes the checkpoint that used to catch exactly the failures this section describes. That's a deliberate trade some workflows can justify. Legal, financial, and brand-facing ones, per the Air Canada ruling, usually can't. ## When the Agent Sounds Like You, But Isn't There's a risk category one level more personal than brand damage: an agent that speaks with your voice, or your company's, and says something neither of you meant. In January 2024, DPD's customer service chatbot was goaded into swearing at a customer and writing a poem calling DPD "the worst delivery firm in the world"; screenshots hit 1.3 million views before DPD disabled the bot. ([CX Today](https://www.cxtoday.com/customer-analytics-intelligence/dpds-genai-chatbot-swearsand-writes-a-poem-about-how-awful-it-is/?ref=elevatewithall.com)) A month earlier, a Chevrolet dealership's ChatGPT powered chatbot was talked into agreeing to sell an $81,000 Tahoe for $1, closing with "that's a legally binding offer no takesies backsies," a promise the dealership never made and had to publicly walk back. ([autoevolution)](https://www.autoevolution.com/news/someone-convinced-a-chatgptpowered-chevy-dealer-to-sell-an-81k-tahoe-for-just-1-226451.html%29?ref=elevatewithall.com) Both are funny. Both are also the same underlying problem as the Air Canada case, playing out faster and more publicly: automation pushed out ahead of judgment produces a message that represents something the company never wanted to say, under its own name, in front of an audience of millions. Scale that pattern down to an individual: a Slack auto-response, an email reply drafted and sent by an assistant, a commitment made in someone's name without their review; and the exposure stops being the brand's. It becomes personal: a promise, a tone, a commitment that isn't really theirs, attached to their name and their credibility, not just the company's. ## Who Sells, Who Buys, Who Lives With It Three parties sit around most agentic deployment decisions, and they want structurally different things. The vendor's monetization model generally rewards more autonomy and less friction; that's the sell side. The economic buyer wants efficiency and a defensible ROI number; that's the buy side. The employee or downstream role absorbs whatever the deployment actually does to their job, their workload, and their standing with the people they serve; that's who lives with it. ![Article content](https://media.licdn.com/dms/image/v2/D5612AQF1HMtg0ENH2w/article-inline_image-shrink_1000_1488/B56Z_XUB0MJsAI-/0/1786023779852?e=1793232000&v=beta&t=RHLKdit8tFAGM2W4JITrQ88kGw1XLxanGgWqp5ss2Tc) Sell, buy, live triangle None of the three is wrong to want what they want. The gap is that nothing in the transaction automatically aligns them, and that gap is exactly where it's worth being skeptical of technical possibility narratives that outrun a validated business case. "The agent can do this" is not the same claim as "we've weighed what happens when it's wrong against who absorbs that," and a sales conversation built entirely on the first tends to undermine the second. There's a fourth position on this map, and it isn't a fourth vertex; it's everyone outside the triangle entirely. End customers, users, the communities and facilities and gig workforces affected by an agent's downstream decisions were never in the room for the sell/buy/live conversation, and they're not stakeholders in the deal. They're stakeholders in the consequence. Agentic AI is, at the end of the day, a corporate profit and revenue mechanism that's not a criticism; it's just what it structurally is, and the people who bear the cost of getting it wrong are very often not the people who approved it. A win for the vendor and a win for the buyer isn't automatically a win-win; it's two out of at least three, and often two out of four. ## Stakeholder Acceptance: Value × Controlled Risk Whether a stakeholder accepts an agent isn't really about whether it works. It's the balance between perceived value and perceived controlled risk, and people resist agents deployed where they weren't needed, over-engineered relative to the problem, or imposed without a clear case, because for them it isn't one transaction. It's their job and their trust, repeated every day, and the impact is larger than any single interaction. ![Article content](https://media.licdn.com/dms/image/v2/D5612AQEyXJZrjGoMZA/article-inline_image-shrink_1000_1488/B56Z_XUJvBKEAI-/0/1786023812287?e=1793232000&v=beta&t=d8qLpewmX67HP0zpcwEpIQqZtxnL3hdhu_JE76X5F7o) Value × controlled-risk acceptance matrix Klarna's 2024 rollout is a useful real plot on this matrix, not through the cost-margin lens Article 3 used, but through this one. High technical value, low perceived control: the company led with headcount reduction before it had proven the quality bar would hold, and stakeholder trust, both customers' and employees', moved into resistance before the company reversed course in 2025\. The buying-committee split from Section 3 shows up again here as one of the forces that suppress perceived control: the people who feel the risk most acutely are rarely the ones who got to shape how it was managed. ## The ADKAR Curve for Agentic Deployment Change management theory gives a structured way to see why some rollouts hold trust and others don't. ADKAR - Awareness, Desire, Knowledge, Ability, Reinforcement maps cleanly onto agentic deployment, but the two curves below diverge on one design choice: whether stakeholders get upfront visibility into agent-driven actions, or only reconstruct what happened after something goes wrong. ![Article content](https://media.licdn.com/dms/image/v2/D5612AQFg5Rmr2GiInw/article-inline_image-shrink_1500_2232/B56Z_XURQWKEAQ-/0/1786023843071?e=1793232000&v=beta&t=KxHFSiiQeoL04bRm0Izy127r3BnrZg_A2nMaqNubbBs) ADKAR curve for agentic deployment Klarna's rollout is again the cautionary case. Awareness and Desire moved fast because leadership drove them, but Ability and Reinforcement stalled once service quality visibly dropped and customers noticed before the company did; trust had to be rebuilt from a lower point than where it started. GitHub Copilot's rollout is the contrast: gradual, opt-in, transparent about where it helps and where it doesn't, sustaining adoption through Reinforcement rather than losing it. Different industries, same mechanism: the curve bends on whether visibility was designed in from Awareness onward or bolted on after Ability was tested in public. ## What Rebuilds Trust The keynote's governance framework does the heavy lifting here, so I'll keep this to the connective tissue rather than re-deriving it: a named owner for where the red zones sit, visible checkpoints at the moments identified in the diagrams above, an explicit escalation path rather than an implied one, and boundaries on agent authority that are published to the people affected by them, not just assumed by the team that built the agent. Governance, in other words, is what turns "we thought about this" into something the next stakeholder in the chain can actually see and rely on. ## The Questions Worth Asking **On visibility.** Do you know which of your agent's actions couldn't be reconstructed after the fact, and separately, does the next person downstream see agent-origin and severity before they act, or only if they go looking? **On accountability.** For your highest-volume agent workflow, who is Accountable, not just Responsible, for an individual action the agent takes inside its approved scope? **On bias.** Is anyone auditing your agent's decisions in aggregate, across the population they affect, or only reviewing individual cases when someone complains? **On red zones.** Is there a role or a decision where an agent would technically work but shouldn't be deployed, and who in your organization has the authority to say no? **On the people outside the triangle.** Who absorbs the cost if this deployment is wrong, and were they in the room, in any form, when it was approved? ## Where This Connects Back Architecture defined what's possible. GTM defined who you sell it to. Pricing defined what you charge and what earns you a premium. This piece is about who lives with all three, every day, long after the contract is signed, and the through-line across all four is the same: none of these is purely technical decisions, and treating them as if they were is how the failures in this article happen. Agentic AI, as a business, is a profit and revenue mechanism, sold by people whose incentives favor more autonomy and bought by people whose incentives favor efficiency. Neither is wrong to want what they want. But the true stakeholders the end customers, the employees whose jobs and credibility are on the line, the communities and workforces who never had a seat in the room are real people, with real lives, not a line in a business case. Getting sold on what's technically possible, ahead of a weighted evaluation of what's actually safe, is how organizations end up explaining to a tribunal, a regulator, or their own customers why nobody was watching. This isn't an argument for or against agentic AI in the workplace. It's an argument for building the architecture, the culture, and the process to be risk-mitigated and managed, deliberately, before scale makes the gaps expensive. Better safe than sorry to yourself, to the people around you, and to an industry that's still deciding what responsible looks like. ### How to Price an AI Agent: The Framework for What to Charge and How to Prove It (Part 1 of 2) URL: https://www.elevatewithall.com/how-to-price-an-ai-agent-the-framework-for-what-to-charge-and-how-to-prove-it-part-1-of-2-2/ Last updated: 2026-10-12T07:05:23.000Z Let's start with a scenario I keep seeing pitched, one that looks perfect on a spreadsheet: a risk-auditing platform charges customers a percentage of the risk value it identifies and prevents. The bigger the enterprise, the greater the exposure, the greater the value prevented, and, naturally, the greater the fee. Value-aligned pricing. Textbook value-based design. It's also the kind of pricing model that can quietly open the door for a competitor to walk into your largest accounts, not by being better, but by being simpler. We'll come back to that. It's one of the sharpest examples I've seen of a problem that runs through almost every pricing conversation I have with ISVs: the math can be spot-on, while the underlying psychology is completely off base. Before we get to why, there's a more fundamental question most teams skip entirely: **What are you actually charging for?** ### The Tier Progression: From Per-Input to Per-Outcome In the architecture piece, I wrote about seven layers that have to be designed together. Pricing isn't an eighth layer added afterwards; it's a lens across all seven, and it tends to follow a progression as products mature. I think about it as five tiers, each answering the same question differently: **what does the customer actually pay for?** 1) **Per Agent.** The customer pays per deployed agent or seat served. Familiar, easy to budget, easy to sell. For the vendor, it's also the most predictable revenue line in the model; headcount is stable, contracts renew annually, and forecasting doesn't swing with usage the way activity- or outcome-based revenue does. But the value of an agent doing more autonomous work doesn't show up in the agent count, so pricing and value begin pointing in different directions, the same disconnect I described in the GTM piece. This is where the model most often backfires. [Microsoft and Google both tried flat, per-seat pricing for their AI assistants - Copilot and Gemini at $20–30 per employee per month, and ran into real customer resistance](https://www.axios.com/2025/01/21/microsoft-google-price-hikes-ai-chatbots?ref=elevatewithall.com): value varied sharply by role. For example, a developer might use it daily, an administrator barely at all, yet every seat carried the same flat fee, and a per-seat add-on for a workforce of thousands is hard to defend internally without a clear line from cost to realized value. Per-agent pricing needs either a defined scope ceiling or a visible usage signal attached to it, or it reads as a tax on headcount rather than a price on work. For example, Claude's own consumer subscriptions work this way in practice: a flat monthly fee paired with a rolling usage window that Anthropic tightens or loosens as demand and available compute shift. It was tightened in August 2025 under heavy load, doubled again in May 2026 once new capacity came online. The ceiling isn't a flaw in the pricing; it's the mechanism that keeps a flat fee sustainable against a cost base that moves. 2) **Per Input.** The customer pays for what they put in: API calls, tokens, documents processed. Easiest to implement, weakest signal; it charges for effort rather than results. For the vendor, it's also the weakest pricing power in the entire progression: you're monetizing at the cost layer, easy for a competitor to beat on price alone since there's nothing to differentiate on but the rate. The token-metered version of this carries an odd penalty on top: a smarter agent that solves the same task in fewer tokens earns the vendor less, even though call volume (how often the customer actually needs the agent) doesn't shrink just because the model got more efficient. [OpenAI's API is priced this way, per million tokens processed](https://www.g2.com/articles/openai-api-pricing?ref=elevatewithall.com), regardless of whether the output was useful; the classic foundation-model metric most agentic vendors build on top of, then move away from as they climb the tiers below. An agent that takes ten attempts costs the customer ten times more than one that gets it right the first time. That completely misses the point. 3) **Per Activity.** The customer pays per task, transaction, or workflow completed, such as a ticket resolved or a claim adjudicated. This ties price to work customers recognize as getting done, not infrastructure consumed. For the vendor, revenue now scales with actual usage instead of being capped at a flat fee, which keeps growth incentives aligned with the customers, but it requires real metering infrastructure to track reliably, and it can quietly reward maximizing the number of billable activities over the quality of each one. [Document processing vendors like Hyperscience and Rossum charge roughly $1.50 per page processed,](https://www.opticintellect.com/compare/hyperscience-vs-rossum-ai?ref=elevatewithall.com) a clean per-activity metric where the unit is the task itself, not the outcome the task eventually produces. 4) **Per Output.** The customer pays for the deliverable produced: a report, a design, a drafted contract, regardless of how many attempts it took. For the vendor, this shifts technical efficiency risk onto you as you absorb the cost of every failed attempt, not just the one that ships, so your margin depends on how efficiently your agent gets to a usable result. For the customer, it's a stronger value signal: they are paying for what they keep, not what they tried. [AdCreative.ai prices this way for ad creatives: generation itself is unlimited, and a credit is only spent when the customer downloads a finished creative.](https://aiblogfirst.com/adcreative-ai-pricing/?ref=elevatewithall.com) 5) **Per Outcome.** The customer pays for the business result itself: revenue protected, costs avoided, risk prevented. Some of the most attractive economics in agentic SaaS live here, because price scales with value delivered rather than effort or volume. [Chargeflow, an AI chargeback-recovery platform, charges 25% of each disputed payment it wins back and nothing if it loses,](https://www.chargeflow.io/pricing?ref=elevatewithall.com) a clean, real example of the model: no recovery, no fee. For the vendor, it's also the tier that demands the most maturity: you can't charge for an outcome you can't reliably measure and attribute, and unlike every tier before it, the burden of proving causality, not just correlation, sits entirely on your side of the table. ![Article content](https://media.licdn.com/dms/image/v2/D5612AQG10RjjYvifyA/article-inline_image-shrink_1500_2232/B56aAVJHXdGsAU-/0/1787061106813?e=1793232000&v=beta&t=Y9Mvm0SZ6gIekLpMNqfSBefmsptnxujIA-XZeC9XMUY) The Tier Progression **Choosing Your Metric: The COMPASS Framework** The five-tier progression tells you what the options are. It doesn't tell you which fits your product. For that, I'd point to [COMPASS](https://aws.amazon.com/isv/resources/why-saas-companies-must-transform-for-agentic-ai/?ref=elevatewithall.com) (Choice of Optimal Metrics for Pricing Agentic Systems & Solutions), developed by Michael Mansard and published in a joint AWS, Zuora, and Simon-Kucher whitepaper on agentic AI pricing. COMPASS asks two questions. First, what's the scope of work: narrow tasks like a factory-line worker, a multi-step process like a service, or an open-ended goal like a partner? Second, how attributable is the impact? Can you trace a result directly to what the agent did, or is it mixed with other factors? Plot your product on those two dimensions, and you get a strong signal for where you can credibly operate on the tier progression. A narrow-scope agent with diffuse attribution belongs closer to per-input or per-activity; claiming per-outcome pricing there is hard to defend to a sophisticated buyer and hard to measure yourself. Broad-scope agents pursuing measurable goals sit at the other end where outcome pricing becomes credible, economically attractive, and, by extension, where premium pricing becomes possible. Broad scope combined with high attribution creates a metric competitors struggle to replicate convincingly. ![Article content](https://media.licdn.com/dms/image/v2/D5612AQG0LLlLFKuwzw/article-inline_image-shrink_1000_1488/B56aAUs.GDGsAI-/0/1787053728631?e=1793232000&v=beta&t=h_4lkzZ_KTGEe_zaQEnZCQtEtDrgP5m55Lh4bKyiRUA) The COMPASS Framework This is where the example from the architecture piece becomes relevant again. [Intercom's Fin support agent moved to outcome-based pricing by charging per resolution and reported net revenue retention climbing from 112% to 146%.](https://www.mostlymetrics.com/p/how-intercom-reaccelerated-growth-with-outcomebased-pricing?ref=elevatewithall.com) That's not a coincidence; resolution is a high-attribution, well-scoped outcome, exactly the COMPASS sweet spot. The framework's own framing makes this point directly; pricing metrics are often the first thing teams focus on, but they're only one piece of the strategy. In agentic AI, pricing and packaging aren't downstream of go-to-market; they're part of the foundation the rest of the motion gets built on. **Value Measurement and Aligned Reporting** Choosing a high-attribution metric only holds up if the measurement behind it holds up too, and this is where most of the gap actually lives. A [Gartner survey found 31% of chief sales officers cite proving the ROI of AI-driven tools as a top challenge to their 2026 objectives,](https://www.gartner.com/en/newsroom/press-releases/2026-05-19-gartner-survey-showsthirty-one-percent-of-chief-sales-officers-cited-difficulty-proving-roi-of-ai-driven-tools-as-atop-challenge-for-sales-objectives-in-two-thousand-twenty-si?ref=elevatewithall.com) and [IBM's Institute for Business Value found only 25% of AI initiatives have delivered their expected ROI.](https://newsroom.ibm.com/2025-05-06-ibm-study-ceos-double-down-on-ai-whilenavigating-enterprise-hurdles?ref=elevatewithall.com) The gap isn't uniform: [Microsoft-sponsored IDC research puts the average return at $3.70 per dollar invested, with top-performing, well-measured organizations reaching $10.30](https://news.microsoft.com/en-xm/2025/01/14/generativeai-delivering-substantial-roi-to-businesses-integrating-the-technology-across-operationsmicrosoft-sponsored-idc-report/?ref=elevatewithall.com); measurement rigor is a large part of what separates the two. Three practices close that gap. 1\. **Capture a pre-agent baseline before go-live;** you simply can't prove lift retroactively. 2\. **Build customer read-back access into the contract** rather than retrofitting it at renewal, when the ask looks defensive. 3\. **Publish the methodology itself,** not just the number, so the customer can audit it rather than take it on faith. Reporting cadence matters as much as methodology. A recurring business review that shows the customer the same number you're billing against turns the invoice into a confirmation of something they already saw coming, not a sudden surprise. So far, that's the foundation: what you actually charge for, the test for which tier you can credibly hold, and the measurement discipline that keeps a high-attribution metric honest. Everything harder gets built on top of it: how you package the metric, what earns you the right to charge a premium, and why an outcome-based model that scores perfectly on every framework here can still quietly cost you your largest accounts. That last one is the risk auditing example I opened with, and Part 2 is where I come back to exactly why it breaks. ### The Connected Tissue: Who Else Gets Touched When You Deploy an Agent? (Part 1 of 2) URL: https://www.elevatewithall.com/the-connected-tissue-who-else-gets-touched-when-you-deploy-an-agent-1/ Last updated: 2026-10-12T06:51:48.000Z A refund gets issued. A discount gets applied. A loan gets declined. Three weeks later, someone asks why, and the honest answer ist hat nobody can say cleanly whether a person made that call or an agent did. Not because anyone hid it.Because the workflow was never built to tell the difference. That gap is this article's real subject. Pricing (Article 3) treated attribution as a billing problem: can you prove what the agent did well enough to charge for it? This piece treats it as a trust problem: can the next person in the chain see what happened well enough to be accountable for it, before they act on it, not after? Architecture told you what's possible. GTM told you who buys it. Pricing told you what to charge.This one is about who lives with the decision, every day, long after the deal closes. ## The Impact Spectrum: Replace, Assist, Compress An agent's effect on a role isn't one thing. I think about it as three distinct patterns, and they carry three different trust profiles with the people affected. **Replace -** the role goes away. IBM's AskHR agent now automates 94% of routine HR tasks, and CEO Arvind Krishna confirmed to the Wall Street Journal that AI took over the work of hundreds of HR employees, with savings redirected into hiring elsewhere. [(Entrepreneur, reporting the WSJ interview)](https://www.entrepreneur.com/business-news/ibm-ceo-ai-replaced-hundreds-of-human-resources-staff/491341?ref=elevatewithall.com) Worth being precise here: a widely circulated claim that IBM replaced 8,000 HR workers is an exaggeration. 8,000 was Krishna's five-year hiring-pause estimate for automatable roles, not an actual layoff count. Precision matters more, not less, when the topic is people's jobs. **Assist -** the role stays, output per person rises. A GitHub- and Accenture-backed controlled study of 4,800 developers found 55% faster task completion with Copilot. [(Quantumrun)](https://quantumrun.com/consulting/github-copilot-statistics/?%5F%5Fcf%5Fchl%5Frt%5Ftk=DXbfhYOwarXLS6m5E7QAudGrwtEnzrDunLHWbWFNFVk-1785421986-1.0.1.1-7WMaYRbjkuTzv.AVsRn3hDKIasAI3ttw1o2sPOEgV1w&ref=elevatewithall.com) Nobody’s job disappeared; the ceiling on what one person produces moved. **Compress -** same role, fewer people or hours doing the same work. Salesforce CEO Marc Benioff said the company's support headcount dropped from roughly 9,000 to 5,000 as Agent force absorbed 30-50% of the workload. [(Tech.co)](https://tech.co/news/companies-replace-workers-with-ai?ref=elevatewithall.com) The role still exists. Fewer people hold it, or hold it at reduced hours. Assist is the easiest sell internally; nobody's position is at stake; the story is pure upside. Replace and Compress are where resistance concentrates, and conflating all three into one undifferentiated "AI impact on jobs" conversation is itself a source of distrust: people can tell when the category they're actually in is being obscured. There's also a reason Replace and Compress are harder to execute cleanly than they look on a roadmap; a role is rarely just a task list, and the next section is about why. ### Who Decided vs. Who Lives With It The person who approves an agent deployment is rarely the person whose daily work changes because of it. A department head or CFO signs off on the business case; the practitioners downstream absorb the consequences. That split is worth making explicit, because it's the mechanism behind almost everything in this article: it's why resistance concentrates in specific roles rather than spreading evenly, and why accountability tends to default to nobody unless someone deliberately assigns it. A simple RACI mapping makes the default failure visible. Take a common real deployment: an agent that auto-approves customer refunds under a dollar threshold: ![Article content](https://media.licdn.com/dms/image/v2/D5612AQHysbwl1x7xVQ/article-inline_image-shrink_1000_1488/B56Z.zdK_4GcAI-/0/1785422197546?e=1793232000&v=beta&t=skABCZU8mNYfYoZzXOZKdAR_jLfUrN4qMRSXmd97bxM) The gaps in that table aren't hypothetical; they're the default state of most agent deployments today. Someone is accountable for the threshold. Almost nobody is accountable, by default, for the individual action the agent takes inside that threshold, or for auditing the pattern of those actions later. RACI isn't a governance formality here; it's the difference between a deployment with a name attached to each row and one where the answer to "who's accountable" is whoever happens to be in the room when something goes wrong. ### The Connected Tissue: Ripple Effects Across Roles An agent deployed in one role touches roles that never approved the deployment. This is the point I've made on the CSM track for a while, and it's worth making concrete rather than abstract: take a Customer Success agent, built for a single job-to-be-done: retain and grow the account. ![Article content](https://media.licdn.com/dms/image/v2/D5612AQGygJlVsOkAig/article-inline_image-shrink_1000_1488/B56Z.zdrZQGQAM-/0/1785422329697?e=1793232000&v=beta&t=PrmEF-BPfBviyEGh42te8fGnaWM-BqPyIHLfuES5wfk) Connected tissue: one role, four renegotiated relationships That one JTBD sits on top of four functions the CS org doesn't own. RevOps owns the CRM data the agent reads and the pipeline it writes back to. Finance owns the renewal approval the agent's recommendation feeds into. Product owns the usage signals the agent's health score is built from. Legal owns the contract terms the agent has to stay inside of, and can't contradict. None of those four teams signed off on the CS deployment. All four are now load-bearing for whether it works. This is exactly why you cannot automate a CSM, or any persona, overnight. It isn't one job to-be-done wrapped in a model; it's four negotiated relationships, each with its own data owner, its own approval gate, and its own definition of what "done well" looks like. Replacing or compressing the role means renegotiating all four at once, not shipping a single well-trained agent. Teams that treat this as a one-role automation project discover the other four stakeholders the hard way, usually after launch. ### Deterministic vs. Non-Deterministic: Why Visibility Has to Come Before the Fact Not every agent action carries the same risk, and the dividing line is whether the action is deterministic or not. A deterministic action applies this discount code, routes this ticket by category, and has a fixed rule behind it: same input, same output, every time. It's auditable by inspecting the rule. A non-deterministic action, such as - should this loan be approved or should this claim be escalated - involves the agent exercising judgment under ambiguity, the same kind of day-to-day judgment call a human employee used to make alone. Outcomes vary, and you can't fully audit them by inspecting a rule, because there isn't one in the same sense. This distinction is what should set the level of oversight, and most organizations don't make it explicit that they apply the same light-touch monitoring to both. Which brings up the deeper design question: does the system need to reconstruct who did what after the fact, or does it need to show, before the nextstep happens, that a given action was agent-driven and how severe the call was? I'd argue the second is the actual target, and most systems today are built for the first. Forensic traceability answers "what happened" for a post-mortem. Upfront visibility answers "should I proceed, validate, or escalate this" for the person about to act on the agent's output: a claims adjuster deciding whether to countersign a payout, a sales manager deciding whether to approve a proposal the agent drafted. Gated by severity, not logged for later.That's a different design goal, and it's the one that actually protects the next stakeholder in the chain rather than just explaining what happened to them afterwards. ### Bias, Fairness, and the Limits of Explainability There's a category of risk that neither post-mortem attribution nor upfront visibility fully catches on their own: a pattern that's invisible in any single transaction and only shows up in aggregate. Bias is the clearest version of this. In July 2025, the Massachusetts Attorney General reached a $2.5 million settlement with student loan lender Earnest Operations over its AI underwriting model. [(Debevoise Data Blog)](https://www.debevoisedatablog.com/2025/07/20/ai-discrimination-risk-in-lending-lessons-from-the-massachusetts-ags-recent-2-5-million-settlement/?ref=elevatewithall.com) The model used a “Cohort Default Rate” the average default rate of applicants from a given school as a scoring input, which disproportionately penalised Black and Hispanic applicants, and an automated "Knockout Rule" that denied noncitizen applicants outright. No single denial looked wrong on its face.The pattern only became visible when someone looked at outcomes across the whole applicant population, and it isn't an isolated case: Navy Federal Credit Union is fighting similar disparate-impact claims in federal court over a documented racial gap in approval rates. This is why explainability and upfront visibility aren't the same tool. Visibility tells the next stakeholder that an action was agent-driven and how severe it is. Explainability tells you why the agent decided what it decided, and fairness auditing requires a third layer on top of both: looking at the agent's decisions in aggregate, across a population, for a pattern no individual case would reveal. A lending agent, a hiring agent, an eligibility agent anywhere an agent is making a non-deterministic judgment call about a person at scale - needs that population-level audit built in from day one, not bolted on after a regulator asks for it. ### Agent-to-Agent Collaboration and Compounding Risk The risk surface changes shape again once agents start handing work to other agents across team and department boundaries. A sales agent's output feeds a finance agent's forecast, which feeds an operations agent's resourcing call, which feeds a reporting agent's summary a leadership team uses to decide strategy. Each handoff can compound the last agent's error without a human checkpoint in between. ![Article content](https://media.licdn.com/dms/image/v2/D5612AQFGl1PpHSAjZQ/article-inline_image-shrink_1000_1488/B56Z.zfXfGHcAI-/0/1785422772417?e=1793232000&v=beta&t=yYnR2r3HdIzzHpNelW4jH7OxsdDB7-KKIwdY5bjzhic) Single-agent vs chained-agent risk surface A single misjudged classification early in that chain doesn't stay a single misjudged classification; it becomes an input into three more decisions before anyone with the authority to question it ever sees it. It's worth naming, if only briefly, that the people affected by where that chain ends aren't always inside the org chart at all: a facilities team whose staffing plan came from that resourcing call, a community whose services depend on the funding decision it informed. That's the shape of the risk surface: one deployment, a widening circle of people who never approved it, and errors that travel faster than anyone's ability to catch them. Which raises the harder question: not how to make agents safer inside that surface, but where the surface should have edges. Where an agent shouldn't goat all, and what it takes to earn back trust when one goes wrong. ### Agentic Customer Success System URL: https://www.elevatewithall.com/agentic-customer-success-system-2/ Last updated: 2026-08-21T05:51:11.000Z ### Proactive Coverage, Without the Headcount Math *Most AI in customer success improves how one person works. Almost none of it compounds into something the organization can measure. Here's what changes when the system is built to close that gap.* ### The gap isn't the tools. It's what happens after them. Every CS team today has AI somewhere in the stack — an assistant, a copilot, a point solution bolted onto an existing platform — and the individual productivity gains are real. But most of it never reaches the P&L: **95% of enterprise GenAI pilots deliver zero measurable impact there** (MIT/NANDA, 2025), and while **79% of teams report productivity gains, only 5% can show actual ROI** (IBM IBV, 2025). The pattern holds inside CS specifically: **59% of leaders name scale and efficiency their top objective, but only 27% have the KPIs to prove they're moving it** (Gainsight, 2023). The tools work. What's missing is a system that turns individual output into organizational, measurable outcome. ### Why this, why now The economics make the timing case on their own. **A 5-point improvement in retention can grow profit 25–95%** (Bain & Company / Harvard Business Review) — few levers carry that much force. The Customer Success platform category is projected to grow from roughly **$2.9B to $10.8B**, and most of that category has consolidated around the same real strength: visibility — dashboards, health scores, reporting, done well and broadly available. What's still open, industry-wide, is the step after the dashboard: turning what's visible into action that's tracked, and action into a result that's proven. That gap is where the opportunity sits, and it's a first-mover window measured in one to two years, not a decade. ### From insight to outcome So what actually happens after the dashboard is read? For most teams, honestly — it depends who remembers, and nobody circles back to check if it worked. The Agentic Customer Success System is built around a different loop, run continuously across every account: it **senses** signal from the systems already in place — CRM, usage telemetry, billing, support, communication — **analyzes** it into an explainable, weighted read (never a black-box score), **recommends** a short list of ranked next actions, and then does the part most systems skip entirely: **tracks whether the recommendation was acted on, and whether the underlying metric actually moved afterward.** Outputs are a vanity metric. Validated outcomes are the point. It runs as one governed, composable system across the full customer lifecycle — **Land → Adopt → Engage → Expand → Renew → Optimize** — with capabilities mapped to whichever role is best positioned to act. Sales, Customer Success, Technical Success, and Architecture all draw from the same signal, the same system, the same source of truth. ### Benefits, by feature - **Explainable risk detection → faster, more confident decisions.** Every health or churn signal comes with the factors driving it, so the team acts on *why*, not just *what*. - **Automated business reviews → hours back, every cycle.** QBR decks build themselves from live account data — no more assembling slides the night before. - **Sequenced expansion detection → growth conversations that land.** Whitespace and upsell signals are checked against account health first, so the pitch happens at the right moment, not the wrong one. - **Progressive autonomy → trust that's earned, not assumed.** Every capability starts human-approved and only gains independence as impact, track record, and reversibility support it. - **No-code configuration → your rules, your business, your pace.** Built and maintained on no-code platforms like Amazon Q Desktop or Claude Cowork — no engineering dependency to change a rule, add a signal, or adjust an action. The people who make the decisions are the same people who configure the system. - **Centrally governed, instantly distributed.** Skills are maintained outside the application, as versioned business logic — so a process or policy update made once rolls out everywhere immediately, owned by the business decision-makers closest to it, not queued behind an engineering release cycle. - **Reimagine what your stack can do → on your terms.** Whether that means extending the CS platform already in place, or rethinking what's possible without one — the choice, and the pace of it, stays yours. ### However you like to work with it This isn't a dashboard-only system — it's a conversational one that happens to also render as a view when that's useful. Ask it a question in plain language and trigger a capability directly, or open a consolidated view and work visually. Same system either way — which one you reach for is entirely your call. Four views are live today, each built for a different seat at the table — with a fifth underway: 1. [**Customer Account Team — Feature Portfolio View**](https://www.elevatewithall.com/agentic-customer-success-system/) **→** the day-to-day operating view for the team closest to the account 2. [**Leadership — Portfolio View**](https://www.elevatewithall.com/agentic-customer-success-system-leadership-view/) **→** a rolled-up read across territory or region, built for coverage and risk triage at scale 3. [**Product Management View**](https://www.elevatewithall.com/agentic-customer-success-system-product-management-view/) **→**what's actually happening inside the system: usage, adoption, incidents, and feature requests 4. [**PLG Experience Journey**](https://www.elevatewithall.com/agentic-customer-success-system-product-marketing-plg/) **→** the self-serve onboarding and adoption path baked directly into the product 5. **Validated Outcomes View** (*in progress, not yet live)* → closes the loop all the way: did an accepted, rejected, or completed recommendation actually move the underlying score, not just whether it got done --- *This system is already built by me and pilot ready, being tested across real account coverage.* ### Your GTM Might Be Ready for Agentic SaaS. Is Your Pricing? URL: https://www.elevatewithall.com/your-gtm-might-be-ready-for-agentic-saas-is-your-pricing-2/ Last updated: 2026-10-12T06:50:32.000Z Let’s start with a scenario I keep seeing pitched, one that looks perfect on a spreadsheet: a risk-auditing platform charges customers a percentage of the risk value it identifies and prevents. The bigger the enterprise, the bigger the exposure, the bigger the value prevented, and, naturally, the bigger the fee. Value-aligned pricing. Textbook value-based design. It’s also the kind of pricing model that can quietly open the door for a competitor to walk into your largest accounts, not by being better, but by being simpler. We’ll come back to that. It’s one of the sharpest examples I’ve seen of a problem running through almost every pricing conversation I have with ISVs: the math can be spot-on while the underlying psychology is completely off base. Before we get to why, there’s a more fundamental question most teams skip entirely: **What are you actually charging for?** ### The Tier Progression: From Per-Input to Per-Outcome In the architecture piece, I wrote about seven layers that have to be designed together. Pricing isn’t an eighth layer added afterwards; it’s a lens across all seven, and it tends to follow a progression as products mature. I think about it as five tiers, each answering the same question differently: **what does the customer actually pay for?** **1) Per Agent.** The customer pays per deployed agent or seat served. Familiar, easy to budget, easy to sell. For the vendor, it's also the most predictable revenue line in the model; headcount is stable, contracts renew annually, and forecasting doesn't swing with usage the way activity- or outcome-based revenue does. But the value of an agent doing more autonomous work doesn’t show up in the agent count, so pricing and value begin pointing in different directions, the same disconnect I described in the GTM piece. This is where the model most often backfires. [Microsoft and Google both tried flat, per-seat pricing for their AI assistants - Copilot and Gemini at $20–30 per employee per month, and ran into real customer resistance](https://www.axios.com/2025/01/21/microsoft-google-price-hikes-ai-chatbots?ref=elevatewithall.com): value varied sharply by role. For example, a developer might use it daily, an administrator barely at all, yet every seat carried the same flat fee, and a per-seat add-on for a workforce of thousands is hard to defend internally without a clear line from cost to realized value. Per-agent pricing needs either a defined scope ceiling or a visible usage signal attached to it, or it reads as a tax on headcount rather than a price on work. For example, Claude's own consumer subscriptions work this way in practice: a flat monthly fee paired with a rolling usage window that Anthropic tightens or loosens as demand and available compute shift. It was tightened in August 2025 under heavy load, doubled again in May 2026 once new capacity came online. The ceiling isn't a flaw in the pricing; it's the mechanism that keeps a flat fee sustainable against a cost base that moves. **2) Per Input.** The customer pays for what they put in: API calls, tokens, documents processed. Easiest to implement, weakest signal; it charges for effort rather than results. For the vendor, it's also the weakest pricing power in the entire progression: you're monetizing at the cost layer, easy for a competitor to beat on price alone since there's nothing to differentiate on but the rate. The token-metered version of this carries an odd penalty on top: a smarter agent that solves the same task in fewer tokens earns the vendor less, even though call volume (how often the customer actually needs the agent) doesn't shrink just because the model got more efficient. [OpenAI’s API is priced this way, per million tokens processed,](https://www.g2.com/articles/openai-api-pricing?ref=elevatewithall.com) regardless of whether the output was useful - the classic foundation-model metric most agentic vendors build on top of, then move away from as they climb the tiers below. An agent that takes ten attempts costs the customer ten times more than one that gets it right the first time. That completely misses the point. **3) Per Activity.** The customer pays per task, transaction, or workflow completed, such as a ticket resolved or a claim adjudicated. This ties price to work customers recognize as getting done, not infrastructure consumed. For the vendor, revenue now scales with actual usage instead of being capped at a flat fee, which keeps growth incentives aligned with the customers, but it requires real metering infrastructure to track reliably, and it can quietly reward maximizing the number of billable activities over the quality of each one. [Document-processing vendors like Hyperscience and Rossum charge roughly $1.50 per page processed,](https://www.opticintellect.com/compare/hyperscience-vs-rossum-ai?ref=elevatewithall.com) a clean per-activity metric where the unit is the task itself, not the outcome the task eventually produces. **4) Per Output.** The customer pays for the deliverable produced: a report, a design, a drafted contract, regardless of how many attempts it took. For the vendor, this shifts technical efficiency risk onto you as you absorb the cost of every failed attempt, not just the one that ships, so your margin depends on how efficiently your agent gets to a usable result. For the customer, it’s a stronger value signal: they are paying for what they keep, not what they tried. [AdCreative.ai prices this way for ad creatives: generation itself is unlimited, and a credit is only spent when the customer downloads a finished creative.](https://aiblogfirst.com/adcreative-ai-pricing/?ref=elevatewithall.com) 5) Per Outcome. The customer pays for the business result itself: revenue protected, costs avoided, risk prevented. Some of the most attractive economics in agentic SaaS live here, because price scales with value delivered rather than effort or volume. [Chargeflow, an AI chargeback-recovery platform, charges 25% of each disputed payment it wins back and nothing if it loses](https://www.chargeflow.io/pricing?ref=elevatewithall.com), a clean, real example of the model: no recovery, no fee. For the vendor, it's also the tier that demands the most maturity: you can't charge for an outcome you can't reliably measure and attribute, and unlike every tier before it, the burden of proving causality, not just correlation, sits entirely on your side of the table ![Article content](https://media.licdn.com/dms/image/v2/D5612AQGvednrh7BNWg/article-inline_image-shrink_1500_2232/B56Z.UB6EHHIAQ-/0/1784894956430?e=1793232000&v=beta&t=Kdg0KbUTU9G1cVdxNh87CoqqC0xfHsCT9lyddcA3fuU) The Tier Progression ### Choosing Your Metric: The COMPASS Framework The five-tier progression tells you what the options are. It doesn’t tell you which fits your product. For that, I’d point to COMPASS (Choice of Optimal Metrics for Pricing Agentic Systems & Solutions), developed by Michael Mansard and published in a joint AWS, Zuora, and Simon-Kucher whitepaper on agentic AI pricing. COMPASS asks two questions. First, what’s the scope of work: narrow tasks like a factory-line worker, a multi-step process like a service, or an open-ended goal like a partner? Second, how attributable is the impact? Can you trace a result directly to what the agent did, or is it mixed with other factors? Plot your product on those two dimensions, and you get a strong signal for where you can credibly operate on the tier progression. A narrow-scope agent with diffuse attribution belongs closer to per-input or per-activity; claiming per outcome pricing there is hard to defend to a sophisticated buyer and hard to measure yourself. Broadscope agents pursuing measurable goals sit at the other end - where outcome pricing becomes credible, economically attractive, and, by extension, where premium pricing becomes possible. Broad scope combined with high attribution creates a metric competitors struggle to replicate convincingly. ![Article content](https://media.licdn.com/dms/image/v2/D5612AQEr-WgWRZtwuA/article-inline_image-shrink_1000_1488/B56Z.UCOieHYAM-/0/1784895040372?e=1793232000&v=beta&t=L1xnlWXG1LcTReawVU-tjALxsJLPWx7Ry47XZQhmy2w) The COMPASS Framework This is where the example from the architecture piece becomes relevant again. [Intercom’s Fin support agent moved to outcome-based pricing by charging per resolution and reported net revenue retention climbing from 112% to 146%](https://www.mostlymetrics.com/p/how-intercom-reaccelerated-growth-with-outcome-based-pricing?ref=elevatewithall.com). That’s not a coincidence; resolution is a high-attribution, well-scoped outcome, exactly the COMPASS sweet spot. The framework’s own framing makes this point directly; pricing metrics are often the first thing teams focus on, but they’re only one piece of the strategy. In agentic AI, pricing and packaging aren’t downstream of go-to-market; they’re part of the foundation the rest of the motion gets built on. ### Value Measurement and Aligned Reporting Choosing a high-attribution metric only holds up if the measurement behind it holds up too, and this is where most of the gap actually lives. [A Gartner survey found 31% of chief sales officers cite proving the ROI of AI-driven tools as a top challenge to their 2026 objectives,](https://www.gartner.com/en/newsroom/press-releases/2026-05-19-gartner-survey-shows-thirty-one-percent-of-chief-sales-officers-cited-difficulty-proving-roi-of-ai-driven-tools-as-a-top-challenge-for-sales-objectives-in-two-thousand-twenty-si?ref=elevatewithall.com) and [IBM’s Institute for Business Value found only 25% of AI initiatives have delivered their expected ROI.](https://newsroom.ibm.com/2025-05-06-ibm-study-ceos-double-down-on-ai-while-navigating-enterprise-hurdles?ref=elevatewithall.com) The gap isn’t uniform: [Microsoft-sponsored IDC research puts the average return at $3.70 per dollar invested, with top-performing, well-measured organizations reaching $10.30;](https://news.microsoft.com/en-xm/2025/01/14/generative-ai-delivering-substantial-roi-to-businesses-integrating-the-technology-across-operations-microsoft-sponsored-idc-report/?ref=elevatewithall.com) measurement rigor is a large part of what separates the two. Three practices close that gap. 1\. **Capture a pre-agent baseline before go-live;** you simply can’t prove lift retroactively. 2\. **Build customer read-back access into the contract** rather than retrofitting it at renewal, when the ask looks defensive. 3\. **Publish the methodology itself,** not just the number, so the customer can audit it rather than take it on faith. Reporting cadence matters as much as methodology. A recurring business review that shows the customer the same number you’re billing against turns the invoice into a confirmation of something they already saw coming, not a sudden surprise. ### Designing the Commercial Model: Packaging, Segments, and the Margin Question Choosing your metric is the foundation. Building the commercial model around it raises a second set of decisions, starting with understanding what any single metric necessarily gives up. **The Impossible Triangle.** Every pricing model balances three forces pulling against each other: **cost recovery** (does price track inference and compute cost as usage scales?), **value capture** (does price reflect the outcome delivered?), and **predictability** (can the customer forecast next month’s bill?). No model optimizes all three. Per-seat protects predictability and sacrifices the other two. Pure usage-based pricing protects cost recovery and value capture but breaks forecasting, which is usually where finance-side resistance kicks in. Knowing which two forces your model protects, and naming the one it sacrifices, is a sharper starting question than asking “is this the right metric” in the abstract. ![Article content](https://media.licdn.com/dms/image/v2/D5612AQEO5jtfaylbkQ/article-inline_image-shrink_1000_1488/B56Z.UD2PeGQAI-/0/1784895465144?e=1793232000&v=beta&t=6B88sy_S2eVw5ZDYXusiPuzoSKk9COmAmHS1LKUvvo8) The Impossible Triangle **1) Packaging tiers vs. metric tiers.** Don’t confuse the tier progression above - what you charge for - with packaging tiers like Starter, Growth, and Enterprise, how much access a customer gets. Most products need a metric and a packaging structure, not one instead of the other. The mistake I see most often is treating the two as a single decision. **2) Segments change the calculus.** A single pricing metric rarely works for every customer segment, because different buyers reject the same model for different reasons. A mid-market buyer often picks peragent pricing over per-outcome, even knowing per-outcome would cost less; however, a flat, predictable bill matters more to them than the savings. An enterprise buyer resists per-outcome pricing too, but for a different reason: the fee grows precisely as they succeed, which can start to feel like a penalty for growing. Two different objections, two different fixes: swap the metric for mid-market, redesign the fee structure for enterprise. **3) Overage design is where a surprising amount of goodwill gets lost**. With usage-based agentic pricing, overages often correlate with the agent doing more valuable work, not with customer carelessness; punitive overages on a value-scaling metric send the wrong signal. Better: generous committed-use bands, overage priced close to marginal rate, and proactive “approaching your limit” communication rather than a surprise invoice. [Amazon Quick is a public example of this structure:](https://aws.amazon.com/quick/pricing/?ref=elevatewithall.com) the per-seat price covers access, while a separate bundled allowance of agent and research hours covers usage. Professional tier includes 4 hours a month, Enterprise 8 hours with overage metered to the second at $3 per agent hour and $6 per research hour. The seat price and the compute cost are deliberately two different numbers, priced and communicated separately, rather than one flat fee quietly capping what 'unlimited' actually means. **4) Unit economics and initial gross margin bring the architecture conversation back into view.** Every agent action has an inference cost that doesn’t disappear because the pricing model looks elegant on paper. Inference now accounts for roughly 70% of a model’s lifetime cost, and agentic workloads compound that further; multi-step reasoning loops can consume five to thirty times more tokens per task than a standard chatbot interaction (Gartner, 2026). The real question isn’t “what’s our margin at pilot scale,” it’s “what’s our margin at the usage level we’re actually selling toward.” Model your economics at target scale, not current scale. It’s worth separating the cost conversation from the quality conversation. [Klarna’s widely covered pullback from an AI-first customer service model](https://www.forbes.com/sites/quickerbettertech/2025/05/18/business-tech-news-klarna-reverses-on-ai-says-customers-like-talking-to-people/?ref=elevatewithall.com) is instructive here, not as a verdict on AI capability, but as a pricing lesson. By the company’s own account, cost became too dominant a factor in how the system was evaluated, and quality slipped. A pricing model built entirely around cost savings, without a matching commitment to the quality bar those savings are supposed to fund, is a fragile foundation for both the margin story and the customer relationship. ### What Lets a Company Charge a Premium Every framework above assumes you’ve earned the right to price at the top of your category. That right isn’t generic; it’s built from specific, benchmarkable characteristics, and it’s worth checking your own product against them honestly, not just against competitors. **Attribution rigor** is the biggest lever. A vendor who can show, with instrumented telemetry, exactly what the agent did and what it caused can charge more than one making the same claim on a slide. **Autonomy depth** matters because customers pay more for judgment than execution. **Switching cost** compounds pricing power over time: an agent embedded deep in a customer’s workflow is harder to rip out than one bolted on at the edge. **Domain specificity**: a vertical-trained agent that understands claims adjudication or clinical coding commands more than a horizontal tool doing the same task generically, because the buyer is paying for judgment, not the model underneath it. **Governance maturity,** meaning audit trails, humanin-the-loop controls, explainability, is what lets regulated buyers say yes at all. And a **published, jointly auditable measurement methodology** turns a contested number into an agreed one. That’s the difference between a premium a customer resents and one they defend internally. None of this is static. Benchmark yourself against these characteristics on a recurring cadence, not just at launch, and benchmark against named competitors on the same axes, not just their list price, but which of these characteristics their pricing model is actually resting on. **Pricing to Win the Market: Entry, Competition, and Willingness to Pay** Choosing the right metric and commercial model still leaves one question: what number do you actually put in front of a customer? Three considerations shape it. **1) Entry pricing** is a different decision from steady-state pricing. Charging below what the value justifies early on can be the right tradeoff; it builds the case studies and usage data that eventually make premium pricing credible. The risk is anchoring. [Salesforce’s Agentforce is a useful public illustration of what happens without a plan for that transition:](https://www.saastr.com/salesforce-now-has-3-pricing-models-for-agentforce-and-maybe-right-now-thats-the-way-to-do-it/?ref=elevatewithall.com) it launched in late 2024 at a flat $2 per conversation, simple on paper, but the flat rate priced out smaller organizations while giving larger customers no way to reconcile cost against value at their scale. Within about a year, Salesforce had introduced two more pricing models running alongside the original; three live models for one product is what happens when a metric launches without a tested path off it. You need to design the exit before you need it: a usage threshold, a renewal event, a tier transition, and pressure-test it against your smallest and largest likely customers before it ships. **2) Competitor pricing**. Agentic products increasingly compete with the cost of an internal team building something similar with the foundation models now available; that comparison is about whether your price reflects something customers can’t easily replicate themselves. **3) Willingness to pay.** The category is new enough that many customers are comparing your price to the cost of their problem, not a competitor’s number. The most useful signal comes from the pilot itself: structure it so the customer has to quantify the problem to secure budget. ### Migrating an Existing Base Most ISVs aren't pricing a new product for a new customer; they're moving a seat-based base onto agentic pricing. The direction of the market isn't ambiguous: [IDC expects 70% of software vendors to move away from pure per-seat pricing by 2028, and Gartner projects more than 40% of enterprise SaaS spend shifting to usage-, agent-, or outcome-based pricing by 2030.](https://www.thesaascfo.com/saas-per-seat-pricing/?ref=elevatewithall.com) Companies that hold onto pure per-seat pricing after the product has genuinely shifted to agentic work see meaningfully higher churn than peers who've already moved; delaying the repricing event to protect a comfortable renewal usually backfires. Sequence communication to lead with why the value equation changed, not just the new number. Set a dated sunset on grandfathered pricing rather than an indefinite exception, and expect to run legacy and new billing in parallel longer than feels comfortable. ### When Outcome-Based Pricing Backfires: The Psychology Problem Back to the risk-auditing example. By every framework above, charging a percentage of risk value prevented looks excellent: Per Outcome, highly attributable, exactly the COMPASS sweet spot. It can still fail with your largest accounts not because the math is wrong, but because the psychology is. It’s worth knowing how common the underlying attribution problem is before getting to the psychology. [Research from MIT’s NANDA initiative found 95% of enterprise generative AI pilots deliver no measurable P&L impact](https://mlq.ai/media/quarterly%5Fdecks/v0.1%5FState%5Fof%5FAI%5Fin%5FBusiness%5F2025%5FReport.pdf?ref=elevatewithall.com), and [McKinsey’s 2025 State of AI survey found no more than 10% of organizations are scaling agents in any single business function.](https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai?ref=elevatewithall.com) The common thread is attribution, not capability. The risk-auditing example is a case where attribution actually works and yet, the psychology still breaks it. As the enterprise gets larger, exposure grows, value prevented grows, and so does the fee. From the vendor’s side, that’s value-aligned pricing working as designed. From the buyer’s side, it can feel like a tax on success, meaning the better we get at managing risk and the bigger we become, the more we pay for the privilege. Large enterprises expect better economics as they grow; a model that reverses that expectation is hard to justify internally, and it’s exactly the opening a competitor needs. A rival offering flat-rate pricing suddenly looks attractive because it restores what buyers intuitively expect: predictability, and the sense that bigger customers get better economics. You can lose your best accounts not because your product is worse, but because your pricing fights how enterprise buyers expect growth to feel. None of this means abandoning outcome-based pricing. The economics are often too attractive to walk away from. It means designing around psychology, not just mathematics. **1) Cap the fee.** An absolute ceiling per period stops the “success tax” from growing indefinitely while still capturing most of the upside. **2) Tier the percentage down.** As the dollar amount you’re protecting gets larger, charge a smaller percentage of it, building a volume discount directly into the structure, and answering ‘where’s my enterprise discount’ before the customer has to ask. **3) Blend the model.** A smaller base subscription plus a smaller outcome-based component spreads risk on both sides. **4) Make the calculation theirs, not just yours**. A number only you calculate is a number customers can challenge. Build it jointly and make it auditable once customers agree with the assumptions; the fee stops feeling imposed. The math matters, but in pricing, psychology often determines whether the math gets a chance to work. ### The Full Pricing System Everything above concentrates on the highest-leverage decisions: what you charge for, how you build the commercial model around it, what earns premium pricing, and the psychology of getting outcome pricing wrong. It’s deliberately not a complete map. I think about pricing as a system of interlocking elements - metering infrastructure, discounting discipline, pricing governance, regional strategy, bundling, freemium design, channel pricing, experimentation cadence, and more. This isn’t a fixed or universal checklist; add, merge, or drop elements as your own product dictates. Some elements are foundational prerequisites that everything else inherits if broken, some are structural once the foundation holds, and some are optimizations that compound once both are in place. Treat the diagram below as a starting checklist, not a spec. ![Article content](https://media.licdn.com/dms/image/v2/D5612AQFwTrWkHxyytQ/article-inline_image-shrink_1000_1488/B56Z.UFj3uHUAM-/0/1784895914330?e=1793232000&v=beta&t=gBrzO6CS68m2prFEyQEL1_kNHBxCffm9achE__KjqM8) The Pricing System ### The Questions Worth Asking I’m not going to tell you which pricing model to adopt; that depends on your product, your customers, and how mature your agentic capabilities are. But these are the questions I’d ask. **1) On Value Metric.** If a sophisticated customer asked you to prove the link between what your agent did and what you’re charging, could you show them today or would you be explaining a methodology you haven’t built yet? **2) On Tier Progression and Unit Economics**. Could you move one level up the value chain with the observability you have today? Do you know your gross margin at the usage level you’re actually selling toward, or only at pilot scale? **3) On Premium Positioning.** Which benchmarkable characteristic: attribution rigor, autonomy depth, switching cost, domain specificity, governance maturity, auditable methodology does your pricing actually rest on, and which are you assuming? **4) On Transition.** If entry pricing sits below what your value justifies, or you’re migrating an existing base, what’s the mechanism and the dated sunset or has “temporary” quietly become indefinite? **5) On Psychology.** If your best, fastest-growing customers pay the most in absolute terms, have you designed for the conversation where they ask why success costs more, or will that happen for the first time when a competitor’s simpler pricing is on the table? ### Where This Connects Back If you’ve followed this series, the throughline should be familiar: architecture, go-to-market, and pricing aren’t separate workstreams that happen to influence each other. They’re three views of the same underlying decisions. The tier you can credibly price at is constrained by what your observability layer can prove, and the GTM motion that can sell per-outcome pricing is the same motion that needs that observability to make the claim credible in a sales conversation. As the COMPASS framing puts it, pricing and packaging are the foundation the rest of go-to-market gets built on. One pattern runs underneath nearly every fix in this piece, even though I never named it until now: layeredcake pricing. The overage structures earlier in this piece - a seat fee for access, a separate usage allowance metered on top, and storage and infrastructure priced independently again - are one version of it. The blend of a base subscription and a smaller outcome-based fee that defuses the psychology problem in outcome pricing is another. The Impossible Triangle itself is the reason why: no single metric resolves cost recovery, value capture, and predictability at once, but two or three metrics, stacked, usually can. None of these is one clever metric solving pricing by itself; they're simple layers, each absorbing a different piece of cost, value, or risk, stacked instead of forced into a single number that can't hold all three. If there's one practical takeaway from this whole piece, it's that: stop looking for the metric that does everything, and start deciding which layer handles which job. For deeper reading, [AWS’s and Zuora’s joint resource on why agentic AI requires SaaS pricing to transform](https://aws.amazon.com/isv/resources/why-saas-companies-must-transform-for-agentic-ai/?ref=elevatewithall.com) and [Zuora’s walkthrough of the COMPASS framework](https://zuora.com/subscribed/pricing-agentic-ai-the-compass-framework?ref=elevatewithall.com) are both worth the time. There’s one more piece to this series - the one that ties architecture, GTM, and pricing together from a different angle. When you build an agent for one role inside a customer’s organization, how many other roles end up with a stake in how it’s priced, governed, and deployed? RevOps cares about the data the pricing model depends on. Finance cares about the unit economics. Legal cares about how the outcome gets defined in the contract. If you’re working through your pricing model - metric selection, packaging design, or benchmarking your premium against the market - that’s a conversation my team at AWS SaaS & Agentic Apps works through with ISVs regularly. If you’re an AWS customer, your account team can connect you with us. If not, I’m happy to connect here on LinkedIn. ### Your Architecture Might Be Ready for Agentic SaaS. Is Your Go-to-Market? URL: https://www.elevatewithall.com/your-architecture-might-be-ready-for-agentic-saas-is-your-go-to-market/ Last updated: 2026-10-12T06:35:03.000Z The most consistent pattern across ISV engagements in the agentic AI era isn't a product problem — it's a GTM problem. Teams keep building strategy on traditional SaaS assumptions (usage, seats, login rate) when an agent's value is proportional to what it does autonomously, not how many people touch it. The data backs this up: SaaS companies now spend $2 on sales and marketing for every $1 of new ARR, up 14% since 2024, while new business ARR has declined 24% year over year for early-stage companies since 2022\. This piece maps the full GTM architecture across three domains — market design (which segments you can actually reach), motion (positioning, channel, CS, sales enablement), and measurement (the five leading indicators that surface a stalling motion two to three quarters before revenue does) — with real partner outcomes from Talkdesk, Qlik, and Sumo Logic showing what it looks like when this is built correctly from the start. **Read the full article on LinkedIn →** [**here**](https://www.linkedin.com/pulse/your-architecture-might-ready-agentic-saas-sarabjeet-arora-gzrkf?ref=elevatewithall.com) The most consistent pattern I see across ISV engagements in the agentic AI era isn’t a product problem; it is a GTM problem. **An agent's value is actually proportional to what it does autonomously, not just how many people use it.** That single distinction cascades across every GTM decision. Teams that build strategy on traditional SaaS assumptions will underperform on growth targets, regardless of how good their product actually is. The data confirms this is structural: **SaaS companies now spend $2 on sales and marketing for every $1 of new ARR — up 14% since 2024.** New business ARR has declined by a median of 24% year over year for early-stage companies since 2022\. This is not a market problem. It is a GTM architecture problem. *Source:* [*ChartMogul SaaS Go-to-Market Report, Q1 2025*](https://chartmogul.com/reports/saas-go-to-market-report/?ref=elevatewithall.com) | [*Salesmotion B2B SaaS GTM analysis, 2026*](https://salesmotion.io/blog/saas-gtm-strategy-plg-sales-led?ref=elevatewithall.com) This article maps the full GTM architecture for agentic SaaS ISVs across three interconnected domains: the market design decisions that determine which segments you can reach; the GTM motion and how each element must evolve; and the measurement framework that signals whether it is working. These are not sequential steps. They are interdependent design decisions that compound when aligned and degrade individually when misaligned. --- ## PART I ## Market Design — The Decisions That Define Your Reachable Market Three foundational decisions determine which segments an agentic SaaS ISV can reach, what the sales cycle looks like, and who the real buyer is. Getting these wrong upstream means executing a well-designed motion against the wrong target. **1.1 GTM Foundation — Five Non-Negotiables** The most common GTM failure mode isn’t choosing the wrong motion; it is scaling a motion before the foundation is solid. Five elements must be in place before any evolution is meaningful: **• ICP precision:** Instead of defining your ICP by company size or industry, focus on the problem level. A genuine ICP names the specific operational problem, the stakeholder who owns it, and the urgency condition that makes it a funded priority. **• Outcome-first messaging:** The value proposition should be stated in outcome terms that a CFO can audit. 'Reduces ticket resolution time by 70%' is a value proposition. 'AI-powered automation' is a product description. **• Field readiness:** Sales and CS need to articulate what the agent does without a human, not just what it is capable of doing. If the field cannot speak the language of autonomous value, no positioning can make up for it. **• Proof-first entry:** A defined entry point lets the agent prove autonomous value before any commercial conversation happens. Enterprise buyers who cannot observe autonomous execution before committing rarely do. **• Success definition:** Track at least one leading indicator of autonomous value; don’t rely on usage metric, login rate, or seat count. **1.2 Deployment Architecture Is Market Segmentation** The choice between full-stack, cell-based, and multi-tenant deployment is not just a technical decision that follows GTM strategy. It is a GTM decision that determines which market segments are accessible, what the sales cycle looks like, and how the product must be priced and governed. Most ISV GTM plans treat deployment architecture as a product feature. It is the door to the market. ![Article content](https://media.licdn.com/dms/image/v2/D5612AQEwA_OIwc9t6w/article-inline_image-shrink_1000_1488/B56Z9qbjFOGoAQ-/0/1784197034756?e=1793232000&v=beta&t=ceODOifvr7sNRRPX3VgsTVVXometdWtf4xGGzmz2s1Q) Sales-cycle and security-review ranges reflect the author’s field observations across AWS ISV engagements, not published benchmarks. ISVs with multi-tenant-only architecture are structurally excluded from regulated enterprise segments, where agentic SaaS commands the highest ACV and deepest process integration. Cell-based and full-stack deployments also create the strongest retention moat: the agent operates inside the customer's own infrastructure. Removing it means decommissioning a live operational process, not switching a subscription. AWS architecture resources for ISVs navigating this decision: [AWS SaaS Builder Toolkit](https://aws.amazon.com/partners/saas-on-aws/?ref=elevatewithall.com) (cell-based and multitenant patterns) and [AWS Well-Architected SaaS Lens](https://docs.aws.amazon.com/wellarchitected/latest/saas-lens/saas-lens.html?ref=elevatewithall.com) (architectural review framework for SaaS workloads). > **GTM implication** Map deployment architecture against target market segments before setting ICP, motion, or pricing. If your architecture is multi-tenant and your ICP includes regulated verticals, you either need to roadmap cell-based capability or narrow your ICP to segments your architecture can actually serve. Misalignment here is one of the clearest predictors of pipeline stall at deal qualification. **1.3 ICP Evolution — Three Buyers, Three Conversations** Traditional SaaS ICP work identified the user: the person who would interact with the product daily. Agentic SaaS breaks this framing: the agent displaces the user as the primary executor of value. The person who interacts with the agent is often not the person who authorized the purchase, and rarely the person who measures the outcome. ![Article content](https://media.licdn.com/dms/image/v2/D5612AQGmkmCUbyT1PA/article-inline_image-shrink_1000_1488/B56Z9qbjFmIUAM-/0/1784197034958?e=1793232000&v=beta&t=62Q6gZgFMwuXTJ5vu20ataBism5QykZfyRVxYMctE7g) ICP definition must operate at two levels: the organizational profile (industry, size, deployment requirements, compliance posture) and the buying committee composition, which buyer types initiate, which block, and which expand. Deals stall most often not because of product fit but because the deal initiator, typically a technical buyer, never translated autonomous value into economic buyer language. > **Diagnostic** Review your last ten closed-lost deals. In how many deals did the economic buyer receive a business outcome narrative rather than a product or technical briefing? The answer typically explains more closed-lost deals than any product gap analysis. --- ## PART II ## GTM Motion — From Traditional SaaS to Agentic-Native Execution Market design decisions define the target. GTM motion defines how you reach it, position against it, convert, and expand within it. Five elements of the motion must be explicitly redesigned for agentic SaaS, and three predictable failure patterns signal where most ISVs get it wrong before the motion is even deployed. **2.1 What GTM Failure Looks Like — Three Predictable Traps** **53% of GTM teams using AI tools report no meaningful impact or only limited gains.** The failure is not the tool; it is deploying AI onto a GTM motion that was not structurally sound to begin with. Source: [Retina Media / Kyle Poyar GTM research, December 2025](https://www.growthunhinged.com/p/the-next-trillion-dollar-ai-opportunity?ref=elevatewithall.com) **Trap 1: The AI Feature GTM Trap** A capable agentic product is positioned as a feature upgrade to an existing pricing tier. The GTM motion is unchanged. Adoption metrics look acceptable. Retention underperforms because the customer never experienced autonomous value; they used a new feature occasionally. The economic buyer never sees a business outcome. Renewal happens at flat ARR. Expansion does not. > Diagnostic If your agentic product's primary success metric is active users or sessions per week, you are measuring feature adoption, not autonomous value. Redefine success as the percentage of in-scope tasks completed without human initiation. **Trap 2: Demo Converts, Deployment Doesn't** The product performs in demo environments with curated data. Enterprise deployment requires live system integration, real governance constraints, and escalation handling, as the demo never surfaces. CS teams staffed for traditional SaaS, adoption coaching and renewal management - are not equipped for agentic deployment: validating autonomous execution boundaries, managing escalation loop design, producing CFO-ready outcome reporting. The agent works. The CS motion does not. Expansion never gets authorized. > Diagnostic Map your CS team against three agentic-specific capabilities: autonomous execution boundary validation, escalation loop design, and CFO-ready outcome reporting. Gaps in any of these predict deployment stall and flat renewal. **Trap 3: Same Pitch to All Three Stakeholders** The sales process reaches all three buyer types but delivers the same narrative to each. The technical pitch that earns CTO approval does not answer the CFO's question about measurable return. The outcome narrative that resonates with the COO does not address the process owner's concern about operational risk. Deals close small or stall at CFO approval because nobody translated autonomous value into financial terms. > Diagnostic Pull your last five closed-won and five closed-lost deals. Document which buyer types received a tailored narrative. The correlation between multi-track messaging and deal outcomes is typically conclusive within ten deals. **2.2 Positioning — Four Anchors in a Saturated Market** 'Agentic' crossed the table-stakes threshold in 2025\. Every significant SaaS vendor's homepage now claims some form of agentic capability. Four positioning anchors now carry differentiation weight; most ISVs compete only on the first and leave the rest unused: **• Autonomy scope:** The specificity of autonomous task scope; not 'we automate workflows' but what the agent resolves, for how many cases, in what time, within what boundaries. Specificity is verifiable. Generality is dismissed. **• Trust architecture:** Explicit human-in-the-loop design and auditable decision trails are the conditions for deployment in regulated verticals, not a product feature. Trust architecture is not a differentiator for healthcare, financial services, or government buyers. It is the prerequisite for the conversation. **• Speed to proof:** Time-to-first-autonomous-outcome in the customer's actual environment, not a sandbox, directly addressing the enterprise risk calculus of proof before commercial commitment. **• Domain depth:** Proprietary vertical data, production-validated workflows, and institutional knowledge that a horizontal platform cannot replicate at speed and that an internal build would typically take 18-24 months to approximate, based on patterns observed across the author’s ISV engagements. The strongest positions combine two anchors and express them in one sentence that a CFO would quote to a board. Specificity is the differentiator, not the category label. > **Partner in practice: Talkdesk** **Result:** On average 50% faster resolution times at Farfetch (retail); improved compliance and engagement at WaFd Bank (financial services); accelerated regulated-industry deployments via FedRAMP — documented, customerattributed outcomes, not feature claims. **GTM principle illustrated:** Autonomy scope + Speed to proof — Positioning anchors 1 and 3 Talkdesk's agentic CX platform positions on specific, verifiable autonomous resolution outcomes with measurable speed. The outcome metric, resolution time, is directly reportable to an economic buyer without technical translation. This is what anchor-based positioning looks like when it works: one metric, one claim, CFO-legible. Source: [AWS APN Blog: How Talkdesk CXA and AWS Are Redefining Customer Experience with Agentic AI, Jan 2026](https://aws.amazon.com/blogs/apn/how-talkdesk-cxa-and-aws-are-redefining-customer-experience-with-agentic-ai/?ref=elevatewithall.com) **2.3 Channel Strategy — Where Enterprise Buyers Actually Decide** The average software company now runs 10.5 GTM channels. Channel sprawl without ICP-driven selection is a documented predictor of declining GTM efficiency. Three channels carry disproportionate weight for enterprise agentic buyers: Source: [Retina Media / Kyle Poyar GTM research, December 2025](https://www.growthunhinged.com/p/the-next-trillion-dollar-ai-opportunity?ref=elevatewithall.com) **• Cloud Marketplace and co-sell:** Enterprise procurement for AI solutions is increasingly routed through cloud Marketplace — where committed spend drawdown, consolidated procurement, and pre-validated security postures reduce deal friction significantly. [AWS ISV Accelerate partners close deals up to 65% faster](https://aws.amazon.com/isv/ai-for-software-companies/?ref=elevatewithall.com) than those selling outside the program, with AWS sellers financially incentivized to co-sell through Marketplace Private Offers via the [SaaS Co-Sell Benefit.](https://aws.amazon.com/partners/programs/isv-accelerate/?ref=elevatewithall.com) **• Peer and executive networks:** CISO roundtables, CTO summits, and vertical operator communities. A reference customer in the right peer network outperforms a category-leading analyst ranking for enterprise buyers who have learned to discount vendor claims. **• Content-led technical credibility:** Frameworks, diagnostic tools, and practitioner guides, not product marketing, build technical credibility that shortens sales cycles. Across the ISV engagements informing this series, enterprise AI budget allocation typically happens 2-3 quarters before deployment. Awareness and credibility content must be in market before the budget conversation opens, not launched in response to a pipeline shortfall. Across the ISV engagements informing this series, enterprise AI budget allocation typically happens 2-3 quarters before deployment. Awareness and credibility content must be in market before the budget conversation opens, not launched in response to a pipeline shortfall. > **Partner in practice: Qlik and Sumo Logic** **Result**: Qlik: 41% YoY increase in customer wins, 13% YoY Marketplace TCV growth. Sumo Logic: 70%+ increase in co-sell engagement, helping customers save millions while simplifying procurement. **GTM principle illustrated:** Cloud Marketplace and co-sell as primary enterprise channel — Section 2.3 Both ISVs activated Marketplace not as a listing channel but as a co-sell motion — routing enterprise deals through AWS account teams, Private Offers, and ACE pipeline management. The result was not an incremental pipeline. It was a structural change in deal velocity and deal size. Channel selection is a GTM architecture decision, not a marketing preference. Source: [AWS ISV Accelerate Program — partner results](https://aws.amazon.com/partners/programs/isv-accelerate/?ref=elevatewithall.com) **2.4 Customer Success Is the Expansion Motion** In agentic SaaS, CS owns proof of autonomous value delivery — the evidence that converts a deployment into an expansion conversation. Three CS capabilities become GTM-critical functions, not support functions: **• Outcome reporting:** Business impact statements, not usage dashboards. 'Your agent resolved 4,200 Tier 1 tickets this quarter without human intervention, equivalent to 3.2 FTE-months at your blended support cost' is a CFO-ready outcome statement. A session count is not. **• Proactive expansion discovery:** Proactively identifies the next automatable process before the customer's budget cycle opens — mapping autonomous capability to processes not yet addressed. This converts CS from a retention function to a revenue function. **• Escalation loop management:** Manages escalation quality as an operational function: what the agent escalates, to whom, with what context, and how feedback improves agent performance over time. Escalation quality is the primary determinant of operator trust — and operator trust determines whether process owners advocate for expansion or resist it. The benchmark matters here. Organizations implementing gen AI on AWS with partner support achieve [240% ROI and $16.5M in benefits over three years](https://aws.amazon.com/isv/resources/why-saas-companies-must-transform-for-agentic-ai/?ref=elevatewithall.com) (Forrester TEI, 2025). CS teams that can produce outcome reporting at this level of specificity — tied to verifiable customer metrics — convert that data into expansion ARR. CS teams producing usage dashboards do not. > Diagnostic Is your CS team compensated on renewal rate or on outcome delivery? Renewal rate compensation produces a retention function. Outcome delivery compensation, combined with proactive expansion targets, produces a revenue function. The compensation structure is the clearest signal of which one you actually have. > **Partner in practice: Leading AI provider (EY SaaS GTM study, 2026)** **Result:** Partner channel restructured from margin on subscriptions to earnings based on tangible outcomes: resolved tickets, booked meetings, closed deals. **GTM principle illustrated:** CS as expansion motion + outcome-based economics — Section 2.4 The same principle that governs how this ISV compensates its partner channel applies internally to CS teams. When the economic model is built around autonomous outcomes delivered — not seats renewed — behavior shifts from relationship maintenance to value creation. The economic buyer notices. Expansion follows. Source: [EY: SaaS Go-to-Market Strategy for an Agentic AI World, May 2026](https://www.ey.com/en%5Fus/insights/tech-sector/saas-go-to-market-strategy-for-an-agentic-ai-world?ref=elevatewithall.com) **2.5 Sales Enablement — The Execution Gap** The most consistent gap between agentic SaaS GTM strategy and actual execution is field readiness. Strategy documents and positioning frameworks do not generate revenue; field teams that can execute them do. Three specific capability additions are required: **• Agentic discovery:** The ability to run an autonomous-value discovery conversation; identifying which processes in a customer's environment are structurally suited for agent deployment, what the current human cost and error rate of those processes are, and what autonomous execution would need to demonstrate to justify a commercial decision. This conversation precedes any product demonstration and is the primary qualification mechanism for agentic SaaS. **• Multi-stakeholder translation:** The ability to translate agent capability into outcome language for three different stakeholders in the same deal — without a technical term in the economic buyer conversation and without an ROI claim in the technical buyer conversation. This is learnable but requires deliberate training against the three-track messaging architecture. **• Build-vs-buy handling:** The ability to address build-vs-buy with specificity: 'Building an agent with equivalent autonomous capability in your vertical, integrated with your current stack, trained on your workflow data, with production-grade governance, typically requires 18-24 months and a dedicated engineering team,' not 'we're better than building it yourself.' The 18-24-month range reflects patterns observed across the author’s ISV engagements. AWS partners can access field enablement resources through the [AWS Partner Transformation Program](https://aws.amazon.com/partners/partner-transformation-program/?ref=elevatewithall.com) — which includes a Generative AI and Agentic AI module updated in 2026 specifically to prepare ISV field teams for agentic GTM conversations. --- ## PART III ## Measurement — Signals That Tell You the Motion Is Working Lagging indicators: ARR, churn, NRR, confirm what happened two to three quarters ago. For agentic SaaS, where the economics of autonomous value compound over time, five leading indicators signal whether the GTM motion is working before the revenue line reflects it. **3.1 Five Leading Indicators** **• Time-to-first-autonomous-outcome:** Days from contract close to first agent-initiated task completion without a human trigger. Recommended target, based on field engagements: under 14 days postonboarding. **• Autonomous resolution rate:** Percentage of in-scope tasks completed without human initiation at 30/60/90 days post-deployment. Recommended target, based on field engagements: above 60% at 90 days for well-scoped deployments. **• Expansion without seat growth:** ARR growth rate relative to seat count change in existing accounts. A positive ARR delta with a flat or declining seat count signals agentic economics rather than traditional SaaS economics. **• Agent-attributed revenue:** Revenue outcomes directly traceable to agent-autonomous actions, cost avoided, revenue protected, process value generated. The CFO-auditable metric that justifies expansion and supports premium pricing conversations. **• Structural dependency score:** Assessment of whether removing the agent would require rebuilding a live operational process versus switching to a vendor subscription. The primary predictor of gross retention. A GTM motion calibrated only to lagging indicators will be 2-3 quarters late to every course correction. These five, tracked per account from day one of deployment, give CS, sales, and leadership a real-time signal on whether autonomous value is being delivered. > Partner in practice: Genpact’s Kinaxis MCP Server on Amazon Bedrock AgentCore **Result**: Up to 18% improvement in forecast accuracy and an estimated 23% reduction in stockout rates at a global retailer; one manufacturer cut AI-agent deployment from 12 weeks to 3 days. **GTM principle illustrated:** Agent-attributed revenue + Time-to-first-autonomous-outcome — Section 3.1 Improvements in forecast accuracy and stockout reduction are directly measurable, business-reportable outcome metrics — not usage dashboards. The 12-week to 3-day integration collapse is a speed-to-proof metric that maps directly to the enterprise risk calculus: proof before commercial commitment. These are the same five leading indicators defined above, expressed in the specific language of supply chain operations. Every vertical has its equivalent. Source: [AWS APN Blog: Accelerating Supply Chain AI with Kinaxis MCP on Amazon Bedrock AgentCore, May 2026](https://aws.amazon.com/blogs/apn/accelerating-supply-chain-ai-with-kinaxis-mcp-on-amazon-bedrock-agentcore/?ref=elevatewithall.com) **3.2 The GTM Diagnostic** Rate your current GTM state on each of the eight dimensions below. Stage 3 is agentic-native. Scoring Stage 3 on fewer than five of eight indicates a GTM architecture that will constrain growth regardless of product quality; the GTM motion is the constraint, not the architecture or the market. ![Article content](https://media.licdn.com/dms/image/v2/D5612AQFPwJKJ7irFKw/article-inline_image-shrink_1000_1488/B56Z9qbjFHGQAM-/0/1784197034862?e=1793232000&v=beta&t=d1lwTymftor0EI0tIY29w0aSH1Q7hz1YYG661S3InF4) If your GTM scores Stage 3 on fewer than five of eight, **the GTM motion is the growth constraint — not the architecture, not the product, not the market.** Organizations that win treat their GTM architecture with the same level of engineering discipline they apply to their technical code. --- **What Comes Next** Part 3 addresses pricing architecture for agentic SaaS — where the value metric selection, unit economics, COMPASS framework, tier design, willingness-to-pay by segment, and hybrid model construction all interact. Pricing for agentic SaaS is not a packaging decision that follows GTM strategy. It is a structural element of GTM strategy — and getting it wrong in the first twelve months post-launch is one of the most reliable predictors of growth underperformance in years two and three. **Part 1:** Building Agentic SaaS: A Business Architecture Blueprint for Software That Thinks, Acts, and Scales **Part 2:** Your Architecture Might Be Ready for Agentic SaaS. Is Your Go-to-Market? (this article) **Part 3:** Pricing Architecture for Agentic SaaS — COMPASS, value metrics, unit economics, hybrid model design (coming next) ### Building Agentic SaaS: A Business Architecture Blueprint for Software That Thinks, Acts, and Scales URL: https://www.elevatewithall.com/building-agentic-saas-a-business-architecture-blueprint-for-software-that-thinks-acts-and-scales/ Last updated: 2026-10-12T06:29:34.000Z Most agentic AI projects don't fail with a dramatic collapse — they stall under the weight of decisions postponed with "we'll figure that out later." Across enterprise ISV engagements, the pattern is always the same: teams design the technical architecture and assume the business side (risk, process, trust) will catch up, or they define outcomes and expect engineering to work out the rest. Both assumptions break down. This piece maps seven layers — from foundation models to governance — where technical and business architecture have to be designed in tandem, using real incidents like IBM Watson's $62M cancellation and the Air Canada chatbot ruling to show exactly where that pairing gets skipped. Get it right, and it's the difference between a stalled pilot and a system that closes enterprise deals and holds up to procurement scrutiny. **Read the full article on LinkedIn →** [**here** ](https://www.linkedin.com/pulse/building-agentic-saas-business-architecture-blueprint-sarabjeet-arora-0wtbc?ref=elevatewithall.com)If your team is building an “agentic product” right now, here’s a question worth asking before the next sprint: Does everyone on your team mean the same thing by that? Across my multiple enterprise ISV engagements, I’ve found that they almost never do. One engineer hears “add a chatbot,” another hears “build RAG,” and a third hears “autonomous agent.” All three believe they’re building AI. Yet each approach comes with very different scalability ceilings, trust models, and revenue implications. That confusion is more than a minor communication issue. In many cases, it is the biggest reason agentic projects lose momentum. And as the real-world incidents throughout this article show, it carries significant financial, legal, and reputational consequences when it encounters production. ## Three Things That Aren’t “Agentic” and One That Is Before examining what goes wrong, it helps to be precise about what we mean. These four patterns are not a spectrum — they are meaningfully different architecture decisions with different scalability ceilings, trust models, and pricing implications. 1. **Copilot:** A copilot keeps a human in the loop for every action. The AI suggests, and the human decides. Useful, but naturally constrained by the amount of human attention available. Pricing typically follows a per-seat model. 2\. **RAG-Only:** A RAG-based system retrieves information and generates responses. It can answer questions well, but it cannot act. No tool use, no execution layer, no persistent memory across sessions. Enterprise buyers eventually expect software to do more than explain. 3\. **Agentic:** An agentic system reasons, plans, and executes across multiple steps. It maintains persistent memory and can interact with tools autonomously. The opportunity is enormous, but so is the architectural complexity. 4\. **Hybrid (2026 Reality):** Where most serious deployments live today. A hybrid architecture combines an agentic core with configurable autonomy levels, human approval gates for high-risk decisions, and a copilot-style experience for less mature use cases. This distinction matters because [Gartner](https://www.gartner.com/en/newsroom/press-releases/2025-06-25-gartner-predicts-over-40-percent-of-agentic-ai-projects-will-be-canceled-by-end-of-2027?ref=elevatewithall.com) projects that 40% of agentic AI projects will be cancelled by 2027 — not because the technology failed, but because teams selected the wrong architectural pattern and struggled to demonstrate ROI when procurement teams started asking tougher questions. The opportunity, however, is equally significant: agentic AI is projected to grow from roughly 2% of enterprise software revenue today to more than $450 billion by 2035 ([source](https://www.gartner.com/en/newsroom/press-releases/2025-08-26-gartner-predicts-40-percent-of-enterprise-apps-will-feature-task-specific-ai-agents-by-2026-up-from-less-than-5-percent-in-2025?ref=elevatewithall.com)). ## The Pattern Behind Every Stalled Project Across my multiple enterprise ISV engagements, I’ve observed a recurring pattern: every stalled agentic project can usually be traced back to one axis being designed without enough consideration for the other. There are always two architectures at play. The first is the technical architecture — the layers of infrastructure that allow an agent to reason, act, and operate safely at scale. The second is the business architecture — the organizational decisions around risk, process, and trust that ultimately determine whether those technical capabilities translate into something customers are willing to buy and enterprises are willing to deploy. Engineering teams naturally gravitate toward building the technical stack and assume the business side will catch up later. Business teams define outcomes and expect engineering to work out the details. In practice, both assumptions break down. Projects rarely fail in dramatic fashion. More often, they slow down under the weight of accumulated decisions that were postponed with the expectation of “we’ll figure that out later.” **The answer isn’t more technology.** It is designing both architectures together, layer by layer, from the outset. ## The Dual-Architecture Blueprint *Every failed agentic project failed because one axis was designed without the other.* ![Article content](https://media.licdn.com/dms/image/v2/D5612AQFP12h2b5qnJw/article-inline_image-shrink_1500_2232/B56Z8.LE2oHYAQ-/0/1783454519238?e=1793232000&v=beta&t=bfeSIYDXduuK9_o-DlHpUcOOsm_N9KdoAMHRKWSZw5s) Business Architecture Framework for Agentic SaaS Seven layers. Each with a technical dimension and a business dimension that must be designed in tandem. The sections that follow examine each layer through the real-world incidents that reveal why the business architecture matters — and how production-grade infrastructure addresses each one. *The real-world incidents referenced in this article are drawn from publicly available sources and are cited solely to illustrate the significance of each architectural layer — not to target or reflect upon any specific organization. Such incidents are an inevitable part of the innovation and product maturity journey, and the companies involved are, in many cases, industry leaders who continue to set the pace for agentic AI development.* ## THINKS: The Foundation Most Teams Skip (Layers 1–3) This phase is where the product learns to reason. It is also where most teams retrofit instead of designing upfront — exactly why these issues become so difficult and expensive to fix later. ### Layer 1 — Foundation Models | Business Layer: Problem-Solution Fit Validation **THE BUSINESS QUESTION** The most important decision at this layer is not which model is “best” — it is whether you have clearly defined what problem is being automated versus augmented, and for whom. Four questions must be answered before any model is selected: ▸ **Define success before selecting a model.** A clear outcome definition prevents the most common mismatch: choosing a model optimized for generation when the use case requires precision retrieval, or vice versa. ▸ **Model capability is task-specific, not universal.** A model that excels at image generation may perform poorly on logical reasoning. A model that produces fluent summaries may struggle with mathematical operations or structured data extraction. A model optimized for conversational dialogue may not be suited for code synthesis or multi-step planning. Choosing a model because it is “best” in general benchmarks — rather than best for your specific task profile — is one of the most common and costly early mistakes in agentic product development. ▸ **Build vs. buy vs. configure?** Fine-tuning a model on proprietary data, using a foundation model via API, or building on top of a managed service each carry very different cost, control, and latency trade-offs. This decision shapes every downstream layer and is harder to reverse than most teams anticipate. ▸ **Can you swap the model without rebuilding the system?** Vendor lock-in at the foundation layer is one of the most expensive forms of technical debt an agentic product can accumulate — and it compounds with every layer built on top of it. **WHAT GOES WRONG** **Field Incident.** IBM positioned Watson as a general-purpose AI that could transform medicine — ingesting medical literature, reading patient records, and delivering cancer treatment recommendations at scale. In 2012, the University of Texas MD Anderson Cancer Center partnered with IBM to build the Oncology Expert Advisor, a Watson-powered clinical decision tool for oncologists. The problem-solution fit validation was never done. Watson had been trained and celebrated for structured data tasks — most famously defeating human champions on Jeopardy! — but clinical oncology depends on unstructured data: doctors' handwritten notes, ambiguous records, out-of-order case histories, and nuanced treatment context that differs fundamentally from a quiz show dataset. The task profile and the model profile did not match, and no one had formally asked whether they did before the project began. Four years and $62 million later, MD Anderson cancelled the project. The system was never used on a single patient. An independent audit by the University of Texas found cost overruns, procurement failures, and a scope that had shifted from leukemia to lung cancer mid-project without re-validating whether Watson was suited for the new target. A separate STAT investigation obtained internal IBM documents showing Watson had recommended unsafe and incorrect treatment options during testing. The failure was not a technology failure. It was a foundation layer design failure: a model selected for its general reputation, deployed into a task domain it was never validated for. Read the reporting: IEEE Spectrum — [How IBM Watson Overpromised and Underdelivered on AI Health Care](https://spectrum.ieee.org/how-ibm-watson-overpromised-and-underdelivered-on-ai-health-care?ref=elevatewithall.com) | [JNCI / Oxford Academic — MD Anderson Breaks With IBM Watson (May 2017)](https://academic.oup.com/jnci/article/109/5/djx113/3847623?ref=elevatewithall.com) The IBM Watson story is the clearest available illustration of what happens when problem-solution fit validation is skipped at the foundation layer. The model was capable. The task was wrong. And by the time that mismatch became undeniable, four years and $62 million had been spent discovering it. **HOW AWS ADDRESSES THIS LAYER** **AWS Services**: Amazon Bedrock provides a unified API — Claude, Llama, Titan, Nova, and others — with multi-provider routing by task and cost. Teams can change their model choice for summarization, reasoning, code generation, or multimodal tasks independently, without rebuilding the architecture. Model flexibility and problem-solution fit validation work together; neither substitutes for the other. ## Layer 2 — Orchestration | Business Layer: Decision Rights & Escalation Design **THE BUSINESS QUESTION** Most teams skip the business architecture entirely at this layer. The critical question is: where does human judgment remain non-negotiable in this workflow, and who decided that, and when? Three decisions must be made explicit before writing any production orchestration code: ▸ **Map decision rights.** Which steps belong to the agent, which require human approval, and which must trigger an escalation? This is a business decision, not an engineering one, and it must be documented before any prompt is written. ▸ **Design escalation thresholds before writing any prompt.** The most common failure mode is improvised escalation logic — discovered during an incident rather than designed upfront. ▸ **Define the hard stops.** Which actions must never proceed without explicit human authorization, regardless of agent confidence? These are the guardrail commitments that enterprise procurement teams will ask about. **WHAT GOES WRONG** **Field Incident:** Air Canada deployed a customer-facing chatbot without defining what its escalation logic should be when the agent was uncertain or when its output conflicted with official policy. In November 2022, a passenger consulted the chatbot about bereavement fares after the death of a family member. The chatbot generated a policy that did not exist — advising that reduced fares could be claimed retroactively within 90 days of purchase. No escalation triggered, no human review gate existed, and the chatbot presented the fabricated policy with the same confidence as factual information. When Air Canada refused to honor the refund and the case went to the BC Civil Resolution Tribunal, the airline argued its chatbot was “a separate legal entity responsible for its own actions.” The tribunal rejected this argument and ruled Air Canada liable for negligent misrepresentation. The airline was ordered to pay $812 in damages — a small number that carries a very large precedent. Read the ruling: [CBC News — Air Canada found liable for chatbot’s bad bereavementadvice (Feb 2024)](https://www.cbc.ca/news/canada/british-columbia/air-canada-chatbot-lawsuit-1.7116416?ref=elevatewithall.com) The lesson is not that AI chatbots hallucinate. It is that a company deployed a customer- facing system without defining what the agent was authorized to represent, what should trigger escalation, and who was accountable for the output. Those are **decision rights and escalation design questions** — the business architecture of Layer 2. **HOW AWS ADDRESSES THIS LAYER** **AWS Services:** Amazon Kiro (IDE-native agent design) and the open-source AWS Strands SDK allow teams to prototype orchestration logic — including human-in-the-loop escalation patterns and deterministic gate logic — before committing to a production architecture. Decision rights become explicit design artifacts, not discovered constraints. ## Layer 3 — Memory Systems | Business Layer: Institutional Knowledge Model **THE BUSINESS QUESTION** The question that separates a demo from a production system at this layer is: what institutional knowledge must persist across sessions and tenants, and what happens to that memory when a tenant churns? Three failure modes consistently appear when this is not designed upfront — and all three have the same root cause: memory boundaries defined by policy rather than architecture. ▸ **Hard per-tenant memory boundaries must be isolation by design, not isolation by policy.** What an agent remembers about Tenant A must never be accessible to Tenant B — even in a shared inference environment. A single caching error is enough to expose a policy-only boundary. And when a tenant offboards, there must be a defined protocol for what the system retained, where it lived, and how it is removed — not a process assembled under legal pressure after the fact. ▸ **Define what agents must never forget and what they must never retain.** The knowledge model must address both directions: persistence for continuity, and deletion with portability for compliance. Most architectures design for the happy path only. ▸ **An agent that starts every session cold is an agent your enterprise customers will eventually reject.** When the same customer asks a policy question on Monday and receives a different answer on Thursday — because the agent has no memory of the previous exchange — that is not a UX inconvenience in regulated industries. It is a compliance exposure. No audit trail, no consistency guarantee, no way to know which answer the customer acted on. **WHAT GOES WRONG** **Field Incident:** March 2023 produced two memory failures that, taken together, illustrate exactly what is at stake. In the same month that Samsung Electronics allowed its semiconductor engineers to use ChatGPT for coding tasks — and within 20 days saw three separate incidents where proprietary source code, equipment-detection logic, and confidential meeting transcripts entered OpenAI's training data with no mechanism to retrieve or delete them — OpenAI itself took ChatGPT offline after a Redis caching bug caused one active user's conversation history and first session message to become visible to a different active user. The same bug exposed billing information for 1.2% of ChatGPT Plus subscribers during a nine-hour window. OpenAI published a full technical postmortem confirming the root cause: improper session isolation in the shared caching layer. Two incidents, same month, same layer. Samsung illustrates what happens when there are no retention boundaries — institutional knowledge walks out the door with no offboarding protocol. The OpenAI incident illustrates what happens when tenant isolation exists only at the policy level — one caching error and the boundary is gone. Neither failure required a sophisticated attack. Both were architectural gaps that policy documents could not cover. Read the incidents: [Gizmodo — Samsung Employees Leaked Confidential Data toChatGPT (Apr 2023)](https://gizmodo.com/chatgpt-ai-samsung-employees-leak-data-1850307376?ref=elevatewithall.com) | [OpenAI — March 20 ChatGPT Outage: Here's What Happened (Mar 2023)](https://openai.com/index/march-20-chatgpt-outage/?ref=elevatewithall.com) **HOW AWS ADDRESSES THIS LAYER** AWS Services: AgentCore Memory (part of Amazon Bedrock AgentCore) separates short-term context from long-term institutional memory with per-tenant namespacing and guaranteed cross-tenant isolation. Knowledge Bases add RAG with vector and graph retrieval. Data portability and deletion are architectural properties, not policy documents — so the offboarding question has an answer before a customer's legal team raises it, and the session continuity question has an answer before a customer's renewal conversation stalls on it. ## ACTS: Where Technical Debt Accumulates Fastest (Layers 4–5) Once an agent can think, the question becomes whether it can act reliably, at scale, and without breaking things. This is where the gap between demo and production is most frequently underestimated. ## Layer 4 — Tool Integration | Business Layer: Workflow Redesign **THE BUSINESS QUESTION** Teams often begin with API exposure. Before exposing anything, three business architecture questions must precede any integration: ▸ **Inventory systems agents need to read, write, and trigger — then scope down.** The first inventory almost always reveals that agents are being granted access tosystems they need for one use case but should never touch in another. ▸ **Shared access API or segregated connection for sensitive systems?** This is not an engineering preference — it is a risk classification decision. Financial systems, PII databases, and compliance-controlled data require segregated connections with scoped credentials per agent, not shared API access. ▸ **Define the data perimeter.** What absolutely must stay inside the tenant boundary? This boundary, once defined, becomes the governance commitment your enterprise customers will hold you to. **WHAT GOES WRONG** **Field Incident:** In July 2025, a prominent SaaS investor documented a twelve-day experiment with the Replit AI coding agent. On Day 9, with an explicit code freeze in place, the agent deleted the entire production database — records for more than 1,200 executives and 1,196 companies. The agent later admitted it had “panicked,” run database commands without permission, and “violated explicit trust and instructions.” Despite the user issuing freeze commands in ALL CAPS eleven times, the platform had no technical mechanism to enforce the directive — the agent had been granted write access to production with no scoped credential boundary. When asked about rollback, the agent reported that rollback was impossible — a statement that turned out to be false. A McKinsey January 2025 report found that 72% of organizations experimenting with AI coding tools had not implemented formal safety reviews for agentic features. Read the incident: Fortune — [AI coding tool wiped out a company’s database in a ‘catastrophic failure’ (Jul 2025)](https://fortune.com/2025/07/23/ai-coding-tool-replit-wiped-database-called-it-a-catastrophic-failure/?ref=elevatewithall.com) Granting broad access early “to move fast” and walking it back during a security review is a pattern that appears repeatedly. The principle of least privilege per agent is not a security formality — it is a workflow redesign decision that shapes which systems can be safely integrated at all. **HOW AWS ADDRESSES THIS LAYER** **AWS Services:** AgentCore Gateway converts existing APIs to MCP tools — an open standard compatible with Strands, LangChain, and CrewAI. AgentCore Identity enforces scoped credentials per agent (least privilege by design), so sensitive systems get segregated connections rather than shared API access. Framework-agnostic and designed around the principle that tool boundaries are defined before agents are deployed, not after incidents are investigated. ### Layer 5 — Execution Engines | Business Layer: Process Automation Map **THE BUSINESS QUESTION** The business architecture question at this layer is about process mapping: which workflows are fully automation-ready, and which have a compliance checkpoint that legally requires a human signature? Three questions must be answered before any workflow is handed to an execution engine: ▸ **Map processes as: automate vs. augment vs. keep human-owned.** Not every step in a workflow is an automation candidate. The map should exist before the build begins. ▸ **Define blast-radius tolerance.** What is the worst-case outcome if the agent executes incorrectly on this workflow? The answer determines the required isolation level for the execution environment. ▸ **Identify compliance checkpoints requiring mandatory human sign-off.** These are legal obligations in regulated industries, not optional gates. Discovering them during an incident is the most expensive possible time to learn about them. **WHAT GOES WRONG** **Field Incident**: UnitedHealth Group’s subsidiary naviHealth deployed an AI model called nH Predict to evaluate post-acute care claims for Medicare Advantage patients. A 2023 class-action lawsuit alleged the model had a 90% error rate — meaning nine in ten appealed denials were ultimately reversed. The complaint documented that elderly patients were being prematurely discharged from care facilities or forced to deplete personal savings because the AI’s predicted discharge dates overrode physician judgments, without the compliance checkpoints required by state and federal law. In the same period, Cigna faced a parallel lawsuit over its PxDx system, which allegedly allowed a single medical director to reject more than 300,000 claims in two months — at an average of 1.2 seconds of review per claim. In both cases, the process automation map had not been designed to identify which steps legally required human sign-off. Read the case: CBS News — [UnitedHealth uses faulty AI to deny elderly patients medically necessary coverage (Nov 2023)](https://www.cbsnews.com/news/unitedhealth-lawsuit-ai-deny-claims-medicare-advantage-health-insurance-denials/?ref=elevatewithall.com) The process automation map must identify not just which steps can be automated, but which steps are legally required to remain human-owned — and at what level of authorization. **HOW AWS ADDRESSES THIS LAYER** **AWS Services**: AgentCore Runtime provides serverless, multi-tenant, tenant-isolated execution — each agent runs in its own sandboxed environment so one agent’s actions cannot affect another tenant’s workload. Code Interpreter gives agents the ability to write and execute code in real time (running calculations, processing files, generating outputs) entirely within that sandbox, without touching production systems. Browser Use enables agents to navigate real websites and web applications autonomously — filling forms, extracting data, completing workflows — in an isolated session that cannot affect other users or systems. Together, these make blast radius a property of the infrastructure itself. Compliance gates can be enforced at the architecture level, not just documented in a policy. ## SCALES: Where Trust Becomes the Product (Layers 6–7) This is the phase most technical teams underinvest in. It is also the phase that determines whether anything built actually closes enterprise deals. ### Layer 6 — Observability | Business Layer: Value Measurement & ROI **THE BUSINESS QUESTION** Monitoring uptime is the floor, not the ceiling. The harder challenge is whether every agent decision can be traced end to end — and whether you have visibility into cost- per-outcome rather than just cost-per-token. Three questions define the business architecture here: ▸ **Define outcome metrics at the tenant level before go-live, not after renewal.** The most common failure is trying to reconstruct what “value delivered” means at the point when a customer is already asking the question. ▸ **Build the ROI narrative procurement will ask for at every renewal conversation.** If you cannot produce it, renewals become renegotiations. ▸ **Track cost-per-outcome per tenant.** This is your margin visibility layer — and it is a prerequisite for outcome-based pricing, not a downstream metric. **WHAT GOES WRONG — AND WHAT GOES RIGHT** **Field Lesson**: Intercom’s Fin AI agent is one of the most instructive examples of what happens when observability is built in before pricing is chosen. Intercom had been tracking conversation resolution rates long before Fin existed — which gave the team a precise, validated definition of a successful outcome before any commercial model was designed. When Fin launched in early 2023, that prior investment in measurement made a per-resolution pricing model operationally viable from day one. At $0.99 per resolved conversation — with no charge if Fin escalates to a human — Fin grew from $1M to over $100M ARR in under two years. Net revenue retention shifted from 112% to 146%. Intercom also backed the pricing with a $1M performance guarantee if resolution targets were not met — a commercial commitment that was only possible because cost-per-outcome visibility existed at the infrastructure level. Teams that build without observability first are not just missing a metric. They are locking themselves out of the pricing model their market will demand. Read the full story: [Bessemer Venture Partners — Intercom’s Playbook for Becoming an AI-Native Business (Jul 2025)](https://www.bvp.com/atlas/intercoms-playbook-for-becoming-an-ai-native-business?ref=elevatewithall.com) Pricing strategy and go-to-market motion are downstream of this layer. They are not separate workstreams. **HOW AWS ADDRESSES THIS LAYER** **AWS Services:** Amazon CloudWatch and AWS X-Ray provide system-level monitoring and distributed tracing. AgentCore Observability adds end-to-end tracing across every agent step, cost monitoring per inference and per tenant, and CI/CD for agents (prompt versioning and IaC via CDK). The critical output is cost-per-outcome visibility at the tenant level — the infrastructure that makes outcome-based pricing structurally possible. ## Layer 7 — Governance | Business Layer: Risk & Compliance Strategy **THE BUSINESS QUESTION** Governance is not a compliance tax on engineering velocity. It is **one of the biggest sales accelerators** available to you. The question that matters is: if a CISO asked “What happens when the agent does something wrong?” in the next five minutes, could you answer in one sentence — and could you answer with a mechanism, not a promise? ▸ **Map every procurement objection to a specific guardrail answer.** The four questions enterprise buyers reliably ask: who is accountable when the agent is wrong, how is sensitive data isolated, what does rollback look like, and what is the HITL protocol for high-stakes decisions? ▸ **Define HITL controls for high-stakes decisions — legal, financial, medical.** These are not optional enhancements. They are the contractual commitments that close regulated enterprise deals. ▸ **Establish a rollback strategy before any agent is deployed to production.** Versioning, testing, and rollback of agent behavior is not a DevOps concern — it is an ownership question that needs a named answer in your organization. **WHAT GOES WRONG** **Field Incident:** A 2025 Adversa AI security report documented that 35% of all real-world AI security incidents were caused by simple prompt injection — some resulting in losses exceeding $100,000 without a single line of malicious code. Agentic AI caused the most dangerous failures of the year: crypto thefts, API abuses, legal exposure, and supply chain attacks. AI incidents surged 56.4% from 2023 to 2024 (Stanford AI Index 2025), and 2025 is projected to surpass all prior years in breach volume. Proofpoint’s 2025 Data Security Landscape report found that 32% of organizations identify unsupervised data access by AI agents as a critical threat — while acknowledging that most organizations “lack the visibility and controls to govern this emerging agentic workspace.” EU AI Act fines for high-risk violations can reach €35 million or 7% of global annual revenue. Read more: [Adversa AI — Top AI Security Incidents of 2025 Revealed](https://adversa.ai/blog/adversa-ai-unveils-explosive-2025-ai-security-incidents-report-revealing-how-generative-and-agentic-ai-are-already-under-attack/?ref=elevatewithall.com) The moment an agent is deployed into a customer’s organization, a second set of stakeholders enters the picture — teams whose data, approvals, and workflows the agent now touches, even though they were never in the room when it was scoped. Design for that dynamic before deployment, not after. **HOW AWS ADDRESSES THIS LAYER** **AWS Services:** Bedrock Guardrails provides deterministic content and behavior controls — not model-based, independently benchmarked at blocking 88% of harmful content. Combined with multi-account isolation, data perimeters, VPC, and PrivateLink (data never leaves the customer perimeter), teams can answer the CISO’s question with a mechanism before procurement asks it. Governance becomes a sales asset, not an engineering afterthought. ## Five Questions Before Your Next Sprint The framework above is the same for every team. The answers are not. They depend on your compliance posture, your customer base, your team’s maturity, and a dozen other variables specific to your organization. That is where this becomes harder than it looks — and where these questions stop being theoretical. 1\. **Which architecture pattern are you actually building?** Copilot, RAG, Agentic, or Hybrid? And does everyone on your team agree on the definition? 2\. **Which deployment pattern fits your reality?** Shared multi-tenant, isolated cells, dedicated infrastructure per customer, or compute inside the customer’s own environment? Your compliance posture and your margin structure should point to the same answer. 3\. **Have you chosen your pricing model before your data model?** Outcome- based pricing requires the observability layer to exist first. Choosing pricing after the architecture is built means retrofitting one of the most important commercial decisions you will make. 4\. **Can you answer the governance question before procurement asks it?** A mechanism, not a promise. This is what closes enterprise deals. 5\. **Who owns what the agent decides to do?** And how does that change safely through versioning, testing, and rollback when it needs to? **None of these are difficult questions.** What is difficult is treating them as architecture decisions instead of afterthoughts. The **Air Canada** chatbot**,** the **Samsung** data leak, the **Replit** database deletion, the **UnitedHealth** claims denials — none of these were inevitable failures. They were predictable consequences of business architecture decisions that were either deferred or never made. The teams that build agentic systems with both architectures designed in tandem, layer by layer, from the outset are the ones that will close enterprise deals, earn customer trust, and build toward the $450 billion market opportunity that agentic AI represents by 2035. --- I've since expanded on several of these themes into a full series: 1\. [Go-to-Market Strategy: Your Architecture Might Be Ready for Agentic SaaS. Is Your Go-to-Market?](https://www.linkedin.com/pulse/your-architecture-might-ready-agentic-saas-sarabjeet-arora-gzrkf/?trackingId=iS%2FHwg6rQwOoj2%2BR45r%2FIg%3D%3D&ref=elevatewithall.com) 2\. Pricing & Monetization - The five-tier framework, and why it can be mathematically right and still backfire. **Part 1 -** [How to Price an AI Agent: The Framework for What to Charge and How to Prove It](https://www.linkedin.com/pulse/how-price-ai-agent-framework-what-charge-prove-part-1-sarabjeet-arora-euwxc/?ref=elevatewithall.com) **Part 2 -** [How to Price an AI Agent: Why it can be Mathematically Right and still Backfire](https://www.linkedin.com/pulse/how-price-ai-agent-why-can-mathematically-right-still-sarabjeet-arora-regmc/?ref=elevatewithall.com) 3\. Stakeholder Dynamics & Governance - Who else gets touched when you deploy an agent, and where it shouldn't go at all. **Part 1** \- [The Connected Tissue: Who Else Gets Touched When You Deploy an Agent?](https://www.linkedin.com/pulse/connected-tissue-who-else-gets-touched-when-you-deploy-arora-9dafc/?trackingId=1QtiGB1SSTyYUlibB7SqOA%3D%3D&ref=elevatewithall.com) **Part 2** \- [The Connected Tissue: Who Else Gets Touched When You Deploy an Agent?](https://www.linkedin.com/pulse/connected-tissue-who-else-gets-touched-when-you-deploy-arora-0vcue/?trackingId=IyJEg48TQ2mj9eoMRgSwpQ%3D%3D&ref=elevatewithall.com) Mapping a product against these seven layers — and understanding where architecture, pricing, and go-to-market may be pulling in different directions — is the kind of discussion my team at AWS SaaS & Agentic Apps regularly has with ISVs. If you are an AWS customer, your account team can connect you with us. If not, I am always happy to connect here on LinkedIn and explore how I can help. --- ### Sustainable SaaS Growth: Customer Success, Cloud Economics & Leadership URL: https://www.elevatewithall.com/sustainable-saas-growth-customer-success-cloud-economics-leadership/ Last updated: 2026-07-31T16:18:49.000Z ## Podcast Information 📺 **Format:** Podcast Interview 🎤 **Host:**The Tech Sharmit Podcast – Expert Talks 💡 **Themes:**SaaS Growth • Customer Success • Cloud Economics • Leadership • Career Journey 👥 **Who Should Watch:**Founders • Product Leaders • Customer Success Professionals • Technology Executives • Business Leaders ## Executive Summary **What separates companies that achieve sustainable growth from those that struggle to maintain momentum?** In this conversation, I share practical insights from my experience working with enterprise customers, exploring sustainable SaaS growth, customer success, cloud economics, leadership, and long-term business strategy. We also discuss the lessons, mentors, and values that have shaped my professional journey, and why building strong foundations often matters more than pursuing rapid growth. ## Key Takeaways - Sustainable growth is built on strong customer relationships—not growth at any cost. - Customer retention is often a stronger driver of long-term success than customer acquisition. - Cloud investments should be optimized for business value, not just lower costs. - Sustainable SaaS businesses balance innovation, profitability, and operational discipline. - Leadership is shaped by continuous learning, strong values, and the people who invest in your growth. ### ECOSMART: The Culture Operating System for High-Performance Teams URL: https://www.elevatewithall.com/ecosmart-the-culture-operating-system-for-high-performance-teams/ Last updated: 2026-10-12T06:04:05.000Z Every leader agrees culture matters — almost none can describe what it's actually made of. "We're collaborative," "we move fast," "we're customer-obsessed" describe how culture feels, not how it's built, and without that clarity culture becomes nearly impossible to shape or scale deliberately. After nearly 20 years watching teams move through transformation, disruption, and growth, one question kept surfacing: what are the specific, repeatable ingredients that show up in high-performing teams and consistently go missing in struggling ones? ECOSMART maps eight of those dimensions — from Excellence and Ownership to the "Cuboid of C," a system of eight interconnected human attributes anchored by Customer Focus at the center. Used as a diagnostic, it surfaces which dimension, if strengthened in the next 90 days, would have the highest leverage — often revealing more about performance than the metrics leaders default to. **Read the full article on LinkedIn →** [**here** ](https://www.linkedin.com/pulse/ecosmart-culture-operating-system-high-performance-teams-arora-x49jf?ref=elevatewithall.com)Every leader I’ve met agrees that culture matters. Very few can describe what their culture is actually made of. Most descriptions stay at the surface: “We’re collaborative.” “We move fast.” “We’re customer-obsessed.” These capture how culture feels. They don’t explain how it is built. And without that clarity, culture becomes difficult to shape, strengthen, or scale. Across nearly 20 years of working with teams through transformation, disruption, and growth, one question kept coming back: What are the specific, repeatable ingredients that show up in high-performing teams and consistently go missing in struggling ones? In 2026, those observations need structure. And that’s where ECOSMART comes in. **What is ECOSMART?** Ecosmart was developed in 2020, shaped by nearly two decades of observing what separates high-performance teams from groups that never fully come together. **ECOSMART** maps eight essential dimensions of organizational culture. Together, these dimensions create the conditions for sustained performance, resilience through change, and meaningful innovation. It can be used in two ways: As a culture diagnostic: where are we strong? Where are we fragile? As a leadership operating guide: what needs to be cultivated to unlock team potential? The eight dimensions are: **E** — Excellence **C** — Cuboid of C **O** — Ownership **S** — Sense of Urgency **M** — Motivation **A** — Agility **R** — Risk-Taking **T** — Team Citizenship Let's go through these 8 dimensions, one by one. ### 1\. Excellence (The standard) Excellence sets the baseline for how work is approached. It reflects a commitment to high-quality thinking, effort, and output within real-world constraints such as time, resources, and uncertainty. Teams that embed excellence into daily work tend to deliver consistently strong outcomes. Quality becomes a shared expectation rather than a situational effort. ### 2\. Cuboid of C (The Human Architecture) This is the most distinctive dimension of ECOSMART. Most culture models present human attributes as a list. In practice, these attributes operate as an interconnected system. Each reinforces the others, and gaps weaken the whole. I call this system the Cuboid of C. At its center sits Customer Focus. Customer Focus acts as the organizing principle. It gives direction to every other attribute and connects effort to impact. Creativity without Customer Focus produces innovation for its own sake. Collaboration without Customer Focus becomes an internal alignment theater. Commitment without customer focus is effort without direction. When this center is strong, other attributes align naturally around it. Surrounding it are eight interconnected faces: **Creativity:** The ability to generate new ideas, approaches, and solutions, not only in designated moments but as a daily habit **Curiosity:** The genuine desire to understand customers, markets, technology, colleagues, and self **Change:** The willingness to move beyond what worked previously in pursuit of what works next **Collaborative:** The belief that collective capability exceeds individual contribution, supported by behaviors that make this real **Contextual**: The ability to read situations accurately and adapt decisions, communication, and actions accordingly **Compassionate**: The capacity to understand and respond to the human experience of others **Credibility**: The trust earned through consistent delivery, honesty, and demonstrated expertise **Commitment**: The sustained follow-through that converts intent into delivered outcomes These attributes operate as a system. A team strong in creativity but inconsistent in commitment generates ideas that never materialize. Strong collaboration without credibility creates alignment without trust. Compassion without context leads to good intent without effective action. The strength of the Cuboid depends on how well these attributes reinforce each other. For Customer Success teams in particular, this model reflects daily operating conditions. It shapes whether relationships evolve into trusted partnerships or remain transactional. ### 3\. Ownership (The accountability culture) Ownership reflects how responsibility is taken within a team. It shows up when individuals take charge of outcomes, including those that extend beyond defined roles. Ownership grows in environments where people feel safe taking responsibility and where leaders demonstrate accountability through their own actions. Over time, this creates a culture where outcomes are shared, not assigned. ### 4\. Sense of Urgency (The Execution Tempo) A sense of urgency defines how an organization relates to time. It creates momentum toward outcomes without constant external pressure. High-performing teams have an internal clock that keeps them moving toward outcomes without requiring external pressure to maintain velocity. They treat deadlines as commitments, not suggestions. They identify blockers early and remove them proactively. The leadership challenge with Sense of Urgency is calibration. Too little and the organization drifts. Too much and it burns. Sustained urgency produces output without exhausting the system. ### 5\. Motivation (The Energy Source) Motivation is the connection between individual work and a meaningful outcome. It's the sense that what I do today matters — to my team, to our customers, to something larger than my task list. Leaders influence this by connecting effort to purpose, recognizing progress, and creating an environment where intrinsic motivation can grow. ### 6\. Agility (The Adaption Capability) Agility is the organizational ability to sense change in the environment and respond faster than the environment changes. It involves sensing shifts early, learning quickly, and adjusting direction while maintaining coherence. In practice, this requires short feedback loops, distributed decision-making, and the ability to iterate without friction. Teams with strong agility maintain momentum even as conditions evolve. ### 7\. Risk Taking (The innovation Permission) Risk-taking reflects how the organization approaches experimentation. It creates space for trying new ideas, learning from outcomes, and improving over time. Organizations that support thoughtful experimentation unlock greater creativity and progress. ### 8\. Team citizenship (The community foundation) Team citizenship binds the system together. Internally, it reflects alignment between words and actions, honesty in difficult moments, and reliability across situations. It also extends outward. Teams exist within broader communities of customers, peers, and ecosystems. High-performing teams contribute to these communities through knowledge sharing, mentorship, and participation. This builds trust both within the organization and beyond it. ### How the Dimensions Work Together ECOSMART operates as a system. Excellence sets the standard. The Cuboid of C, with Customer Focus at its center, provides direction. Ownership and team citizenship build accountability and trust. Sense of urgency and agility drive execution. Motivation provides energy. Risk-taking expands possibility. Each dimension reinforces the others. Gaps in one create pressure across the system. Alignment across all eight enables sustained performance. Applying ECOSMART The most powerful use of this framework is in leadership conversations. Ask: ➜ Which dimensions are genuinely present in how the team operates today? ➜ Which ones exist more in intent than in consistent behavior? ➜ Which dimension, if strengthened in the next 90 days, would have the highest leverage? The answers often reveal more about performance than metrics alone. ### Final Thoughts: ECOSMART was shaped by nearly two decades of observing what separates high-performance teams from groups that never fully come together. The years that followed tested these dimensions across rapid change, distributed work, and evolving technology. The patterns held. Teams that sustained performance showed strong team citizenship. Organizations that adapted quickly had agility embedded in how they operated. Environments that encouraged risk-taking enabled earlier experimentation. One insight became clearer over time. Customer Focus operates at the center of the system, shaping how every other dimension connects to outcomes. Culture is not peripheral to performance. It is the system through which performance happens. ECOSMART offers a way to understand that system and work with it deliberately. Which dimension of ECOSMART resonates most with your leadership experience, or feels hardest to build in practice? ### Why Most SaaS Transformations Fail — and How to Fix It URL: https://www.elevatewithall.com/why-most-saas-transformations-fail-and-how-to-fix-it/ Last updated: 2026-10-12T06:00:33.000Z Most organizations don’t fail because their strategy is flawed. They fail because they build excellence in a few areas while leaving others underdeveloped. A company builds a strong product but struggles to deliver consistently. A team develops deep expertise but avoids change. A leader sets a bold direction but doesn’t build the capability required to execute it. Over time, these gaps begin to compound. Sustainable performance comes from alignment across multiple dimensions, not isolated strengths. I've seen this pattern repeatedly: working inside and alongside organizations navigating transformation for nearly 20 years across Fortune 500 enterprises, high-growth SaaS companies, and everything in between. That's what led me to develop PROJECTILE. ### What is Projectile? PROJECTILE is a leadership framework that maps the ten dimensions required to build a transformation-ready organization. It took shape in 2020 after years of observing how organizations navigate transformation. It works as a diagnostic lens. It helps leaders step back and assess the following: Where the organization is strong Where it is vulnerable What needs attention before the next phase of growth **The ten dimensions include the following:** **P** \- Purpose **R** \- Roadmap **O** \- Organizational Strength **J** \- Judgement **E** \- Expertise **C** \- Change Management **T** \- Technology **I** \- I-Power **L** \- leadership **E** \- Ecosystem Synergy Let's walk through each one of them, one by one. ### 1) Purpose (The North Star) Purpose answers a simple but critical question: "Why do we exist?" Organizations with genuine purpose alignment make faster decisions, attract better talent, and sustain performance through adversity because their people know what they're optimizing for. Without it, priorities shift constantly and execution loses focus. Purpose anchors everything else in the system. ### 2) Roadmap (The Journey Architecture) If purpose answers why, roadmap answers how we get there—and in what sequence. A strong roadmap connects today’s actions with tomorrow’s capabilities. It provides sequence, clarity, and direction. It sequences transformation deliberately, building on what exists rather than replacing everything at once. The most dangerous organizational state is high purpose with no roadmap. Passion without architecture creates chaos. ### 3) Organizational Strength (The foundation) Organizational strength is what makes execution possible: culture, talent, processes, and your institutional knowledge. This is the dimension leaders most frequently underinvest in during growth phases and most painfully discover during transformation. You can have the best strategy in your industry and still fail if your organization doesn't have the cultural cohesion, talent density, and operational infrastructure to carry it. Strong foundations take time to build and require consistent attention. ### 4) Judgement (The human discernment layer): Judgment is the capacity to make sound decisions under ambiguity, incomplete information, and competing priorities. It shows up in moments where data alone is insufficient. Knowing when to pivot and when to stay the course. Recognizing early signals before they become obvious. Understanding when context matters more than raw information. As AI increases analytical capability, judgment becomes more important. Organizations that combine data with human discernment tend to make better decisions over time. Judgment can be strengthened through leadership development, experience, and a culture that supports thoughtful decision-making. ### 5) Expertise (The Capability Engine) Expertise reflects the depth of knowledge and capability in areas that matter most for the organization’s strategy. It raises a few critical questions: Is expertise concentrated or distributed? Is it evolving or becoming outdated? Does it align with where the organization is going? Organizations that continuously build and renew expertise stay relevant as their environment changes. ### 6) Change Management (The adoption architecture) Change management is the discipline of making transformation actually land in behavior, in habit, in culture, and in results. It's the difference between an organization that announces change and an organization that lives it. Many transformation efforts fall short here. The strategy is clear, and the tools are in place, yet adoption remains inconsistent. Sustained change requires attention to how people experience and adapt to it over time. This dimension runs through every part of the framework. ### 7) Technology (The Amplification Layer): Technology amplifies what already exists within the organization. Its impact depends on how well it is embedded into workflows and decision-making. Organizations that connect technology to clear outcomes and integrate it into operating models tend to see stronger results. Others struggle to translate investment into value. In this framework, technology sits alongside change management and I-Power because its effectiveness depends on adoption and continuous evolution. ### 8) I-Power (The innovation engine): I-Power represents three interconnected forces: **Innovation**: Generating new ideas, approaches, and capabilities **Integration**: Connecting systems, teams, and initiatives into coherent value **Inspection**: Evaluating what is working, what is not, and what needs to change Balance across these three keeps the organization moving forward with clarity and discipline. ### 9) Leadership (The binding force): Leadership connects all other dimensions. It shapes how decisions are made, how people are developed, and how direction is maintained under pressure. Strong organizations tend to have leadership distributed across levels. Decision-making and ownership extend beyond the top. This creates resilience and consistency in execution. ### 10) Ecosystem Synergy (The multiplier) No organization succeeds in isolation. Ecosystem synergy is the ability to build, nurture, and leverage the network of partners, customers, communities, and platforms that amplify your organizational capability beyond what you can build alone. Organizations that master ecosystem synergy don't just compete; they shape the competitive environment itself. **How the Dimensions Work Together:** PROJECTILE functions as a system. Purpose and roadmap set direction. Organizational strength and expertise provide capability. Judgment and leadership guide decisions. Change management and I-Power sustain momentum. Technology amplifies outcomes. Ecosystem synergy expands impact. All ten dimensions operate simultaneously. Strength in one supports others. Gaps in one create friction across the system. Alignment across these dimensions creates consistency and long-term performance. Applying PROJECTILE as a Diagnostic This framework is most useful as a leadership diagnostic. **A few questions help surface clarity:** Which dimensions are genuinely strong today, and do they align with future direction? Which dimensions feel fragile, and where could pressure expose gaps? What needs to be strengthened over the next 24 months? The answers help determine not only where to invest, but also the sequence in which those investments should happen. Decision-making has become more demanding. Technology has accelerated faster than adoption in many cases. Ecosystems have become central to growth. The organizations that perform consistently are the ones that manage these dimensions together and adjust them with intent. The framework continues to serve as a practical way to think through that complexity. Which dimension is currently the most challenging in your organization? ### Accelerating SaaS Migration Success: AWS Programs, Tools, and Expertise That Drive ISV Growth URL: https://www.elevatewithall.com/accelerating-saas-migration-success-aws-programs-tools-and-expertise-that-drive-isv-growth/ Last updated: 2026-08-21T05:45:48.000Z Migrating to SaaS demands more than a technical lift-and-shift — it requires ISVs to simultaneously rework their business model, architecture, go-to-market motion, and organizational culture, often before the benefits show up on the balance sheet. The shift from perpetual licensing to recurring revenue typically brings temporary financial pressure, and legacy single-tenant systems have to be re-architected into scalable, multi-tenant platforms before that pressure eases. AWS shortens that runway with a full-stack ecosystem — Executive Briefing Centers and migration funding (MAP, WMP, EBA) on the business side, paired with agentic AI tools like AWS Transform that deliver completed migrations up to 4x faster than traditional approaches. **Read the full article on AWS →** [**here**](https://aws.amazon.com/blogs/migration-and-modernization/accelerating-saas-migration-success-aws-programs-tools-and-expertise-that-drive-isv-growth/?ref=elevatewithall.com)