--- title: "Outcome Pricing as a Process Question" author: "Daniel Gorld" author_role: "Consulting Director, cbs CX — The cbs Group Salesforce Consultancy" author_url: "https://cx-waves.com/about" publisher: "CX-Waves" canonical_url: "https://cx-waves.com/nodes/outcome-pricing-process-question" date_published: 2026-06-28 date_modified: 2026-09-20 language: en --- # Outcome Pricing as a Process Question Source: Daniel Gorld, CX-Waves — https://cx-waves.com/nodes/outcome-pricing-process-question (published 2026-06-28, updated 2026-09-20) ## Why is outcome-based pricing for AI agents primarily a process design challenge? * **Forces Explicit Definition of "Resolved":** Outcome-based pricing, such as "per resolution," necessitates a precise and predefined understanding of what constitutes a "resolved" case. This clarity is often lacking in existing human-centric service operations. * **Exposes Process Ambiguities:** Many traditional service processes rely on human judgment to navigate gray areas or partial solutions. When billing is tied to a discrete "resolution," these previously unexamined ambiguities become critical design flaws that must be addressed. * **Shifts Focus from Procurement to Operations:** Instead of being a straightforward technology purchase, implementing AI agents with outcome pricing demands a thorough internal review and redesign of service processes to establish verifiable resolution criteria. * **Requires Definitional Ownership:** The vendor providing the outcome-based model typically sets the default definition of "resolved." Companies must proactively define their own resolution logic based on their specific processes to ensure fair billing and align with their operational realities. ## What Counts as Resolved? On June 25, a significant platform vendor introduced a prebuilt service agent with a novel billing principle: per resolution. This means payment is only incurred when the agent successfully resolves an issue, rather than per conversation, per action, or through licensing fees. This approach is presented as a long-awaited commercial simplification in an era of unpredictable AI costs, offering a price tied directly to outcomes and enabling better budget planning. While the promise of this model is significant, it introduces a critical precondition that extends beyond typical invoicing concerns. ### The question the model asks — and that no one has prepared for Paying per resolved case inherently requires a clear, upfront definition of "resolved." While this may seem straightforward, it poses a significant challenge within the complex B2B service operations of industrial companies. Some cases are inherently binary and align well with this model, such as inquiries about delivery status, compatible spare parts, or appointment times. For these processes, where there is a clear, verifiable answer, the concept of resolution fits seamlessly. However, a substantial portion of industrial after-sales scenarios differs significantly. Technical fault diagnoses often involve multiple stages. Configuration questions can depend on conditions that emerge only during interaction. Complaints frequently require clarification of several open points before resolution is reached. This complexity raises questions about what "resolved" truly means when an agent provides partial information before escalation, answers a question without fixing the underlying problem, or satisfies a customer while the internal ticket remains open. These are not merely billing technicalities; they represent fundamental process decisions that many service organizations have never explicitly defined. Human employees typically navigate these ambiguous zones based on experience, but a billing-relevant "resolved" status demands a definition that is predetermined, consistent, and verifiable to prevent disputes. ### The pricing model forces a clarity the process never needed before The true impact of this announcement extends beyond pricing; it lies in its power to transform resolution definition into a stringent design criterion. Service processes can operate with a degree of informality when managed by human personnel. However, the moment billing becomes dependent on a specific outcome, any existing operational looseness becomes apparent and can lead to increased costs or disputes. For B2B industrial companies, adopting such an agent transcends a mere procurement exercise ending in a purchase order. It mandates a foundational process review on the business side, preceding any licensing decisions. This review involves identifying which service processes possess a clear and verifiable "resolved" definition and which rely heavily on human judgment. It also requires determining where the outcome-based model will genuinely create value and where it might inadvertently generate systematic billing conflicts. A crucial point often overlooked in the commercial enthusiasm is that the seller of an outcome-based product inherently shapes the definition of that outcome. This is not an accusation against any specific vendor but an intrinsic characteristic of all outcome-based models—the criteria for "resolved," applicable time or session limits, and counting methodologies are determined by the model's provider. The appropriate response is not distrust, but rather the assertion of definitional ownership. A company that develops its own resolution logic, derived directly from its internal processes, is in a much stronger negotiation position than one that merely adopts the tool's default definitions. ### What decision-makers should do now Outcome-based pricing is a positive advancement, offering a commercially cleaner model that directly links cost to value. However, its effectiveness is directly proportional to the clarity of the underlying process. The true value derived does not originate from the pricing model itself, but from the precision with which a company understands and defines its own service processes. Before any invoices are generated, undertaking an honest assessment is invaluable: "Do we truly understand what 'resolved' means across each of our service processes?" Addressing this question meticulously before implementation enables optimal utilization of the model. Postponing this clarification until after go-live will likely result in costly learning experiences. The AI technology is now mature and ready for deployment. Yet, as is frequently the case, the most critical work lies in the prerequisite process design and definition.