From Selling Tokens or Hours to Selling Outcomes: An Outcome Pilot Workflow for AI-Native and IT Services Firms

Tokens and hours put the vendor's cost on the buyer's invoice, and finance cannot tie that spend to anything it reports. An outcome price fixes that and moves the risk to the seller, so the definition of the outcome becomes the contract. A loose one such as "tickets handled" turns into an argument at the first invoice.

An AI-native company meets this from the product side: the person who tries the product does not own the process it changes, so free usage does not become an enterprise contract. An IT services firm meets it from the other side: procurement compares its rate card with the next firm's, and the offer sounds like hours however it is worded.

Both stall on an open-ended pilot with no pass mark, no date and no decision owner.

Each step fixes something the next one needs. Until you know the unit you will price, you cannot say what it replaces. The motion comes next, because an outcome offer often needs both a self-serve entry and an account-based sale. The plan, the proposal and the price come last, because they need everything before them. The table alongside shows the hand-offs.

Step 1. Pin down the outcome in IMPACT

Input: Answerloop, for VPs of Customer Support at consumer apps with growing ticket backlogs. Outcome: more tickets resolved end to end without a human. Capability: agents that take the action inside the help desk (refund, reorder, address change), with a person approving anything that moves money. Result: 45% of tickets resolved without a human at Example Food Delivery Co in 60 days; first response time down from 6 hours to 2 minutes. Sector AI native, business model software subscription.

What came back: three "only" statements, with the claim kept in brackets "until it is true and you can prove it": the first is bracketed whole, the second only in its closing sentence, the third only in its opening clause. Then a value matrix with one row, my outcome, and the other measures AI native buyers watch: "how often a person has to step in, cost per case or per decision, accuracy on the buyer's own data, time to a working pilot, turnaround time per case." The proof shape it says lands: "A pilot on the buyer's own data, scored against the way the work is judged today, with how often a person had to step in."

How to read it: the measures list is the menu for your contract. Pick one as the billed unit (tickets resolved without a human) and one as the guardrail (how often a person has to step in). The economic buyer, "the owner of the process the AI changes", will weigh term length, users or usage and how the price grows, so the price must answer that. A quirk: the first statement reads "where AI agents that take the action", because the tool slots the capability text in as typed; edit it by hand.

Hand-off: the outcome line and the guardrail become strengths to test in the map of alternatives.

Step 2. Map what the outcome price replaces

Input: four alternatives, each a way the buyer pays today: Competitor A, a help desk chatbot priced per seat; Competitor B, an AI model sold by tokens used; hiring more support agents; and an outsourced team billed by the hour. One weakness each for A and B, and three strengths, including the price per ticket resolved.

What came back: one card per alternative with a neutral question for the buyer, a warning that "nothing about a competitor was looked up", and advice to keep: put the cost of the current approach in the buyer's own figures and "tie the change to a dated event such as a renewal, an audit, a season or a target."

How to read it: the four cards are four pricing models, as in the table alongside; step 6 prices them. For a travel app, the dated event is the peak season. A quirk: the summary opens "AI agents is mapped against 3 competitors", taking my product text as the name, so start that field with the product name.

Hand-off: the pricing gap, that buyers will not sign a seat or token contract, goes into the EPIC audit challenge. The objections "AI gets answers wrong" and "Where does our data go?" wait for step 4, where they become a success criterion and the security review.

Step 3. Score the hybrid motion in GTM Alpha

Input to the EPIC audit: Series A, ACV $60,000, a 75 day deal cycle, NRR 125%, 3,000 addressable accounts, a self-serve sandbox, mostly inbound deals and a global market. The challenge: teams try Answerloop free, but enterprise support leaders will not sign a seat or token contract, and we want to sell a fee per ticket resolved, starting with a 60 day pilot.

What came back: Ecosystem and ABM 7, Product-Led Growth 7, Inbound and Outbound 6, Community-Led 5. The tie went to Ecosystem and ABM by rule: "the lead goes to the motion with lower execution complexity, in the order E, P, C, I." It warned "Hybrid motion detected. PLG for land, Ecosystem for expand", and suggested layering ABM on accounts with 10+ active free users, an example figure. The sector note's usual sale: "A proof of concept on the buyer's own data, then a production pilot with guardrails and human review."

How to read it: the tie is the finding; Ecosystem and ABM leads by a tiebreak, not a margin. My own working rule: let the sandbox win the data or AI lead, and sell the outcome contract account by account to the owner of the support process. Replace the 10+ free users trigger with a sandbox account that has connected a real help desk queue.

Hand-off: the sector's sales motion, proof of concept then production pilot, becomes the shape of the mutual action plan.

Step 4. Write the pilot into a mutual action plan

Input: Example Travel App Co outcome pilot, in evaluation, target close 29 January 2027. Champion VP of Customer Support, economic buyer the COO, evaluators the Head of Data and AI and the help desk administrator. Requirements: a 60 day pilot on refund and booking-change tickets, a fee per ticket resolved, success scored against the current QA checklist, and a person approving every refund. Blockers: the security review of ticket data, and finance wanting a cap on the per-ticket fee.

What came back: "69 working days from 2026-10-26, 95 calendar days", five phases with owners and dates, each requirement as its own success criterion, and an answer per blocker. Use the fee cap answer as written: "one worked example on the buyer's own volumes, with every charge on the page."

How to read it: fix three things first, as in the table alongside. The timing: the live pilot sits at 26 November, a month in, where a 60 day pilot cannot finish. Move the close date, or, my own working rule, sign a paid pilot order first with the conversion terms agreed, and make the COO's sign-off on expansion the close.

The order: the proof of concept on the buyer's tickets is due before the security review, and tickets carry customer personal data, so clear the review first or use redacted tickets. The calendar: the legal review falls on 25 December and the COO's approval on 1 January. Read the "60 day pilot" criterion as scope, not a test.

Hand-off: the success criteria and the two pricing terms, the fee per resolved ticket and finance's cap, go into the proposal's success metrics section, which is where the fee will be billed from.

Step 5. Define the billed outcome in the proposal

Input to the proposal section writer, success metrics section: the same buyer, a fee per ticket resolved without a human with a monthly cap and no fee for tickets handed to a person, and three success measures.

What came back: my three measures listed as the agreed metrics, and a KPI table that holds only the four sector measures, with every baseline set to "Measure first, with Example Travel App Co" and every target and timeline to "Agree with Example Travel App Co". It made up no number. Automated resolution rate matches my share of tickets resolved without a human, but without the QA test, and escalation rate matches another of my measures. Only refunds approved by a person never became a row: add it, and write the QA pass into the resolution row.

How to read it: the fee is billed on that table, so fill the baselines from last quarter's tickets and define resolved. My own working rule: closed by the agent, not reopened within seven days, and passing the buyer's QA checklist. Cut generic bullets such as competitive advantage under Phase 4. The pricing justification section came back thin and points to the ROI business case tool, which is step 6.

Step 6. Price the outcome and close the value case

Put the outcome price next to every way the buyer pays today, on the buyer's volumes. In my example figures: 20,000 tickets a month in scope, $3.50 to handle one by hand, a fee of $1.50 per ticket resolved without a human, a monthly cap of $11,000, and no fee for hand-backs. At 40% resolution, 8,000 tickets earn $12,000, the cap holds the bill at $11,000, and people handle the other 12,000 for $42,000: $53,000 against $70,000 today, a saving of $17,000 a month.

How to read the comparison alongside: the token model looks cheaper only before the buyer's cost to build and run the agent, and it is paid even when resolution falls. The outcome price wins by taking that risk, so say so.

My own working rules, not the tool's. Set the unit fee well below the cost of a ticket handled by hand, so every resolved ticket visibly saves money. Set the cap at or above the target resolution rate, review it quarterly, and agree a peak season cap in advance. This example's cap binds at 36.7% resolution, below the 40% target, so by my own rule it should be $12,000. Watch three kinds of drift: resolved tickets that reopen (credit them), an easier ticket mix flattering the rate (report by ticket type), and volume past the cap, which costs you margin.

Then I ran the ROI business case tool with the buyer's annual handling cost ($840,000), a 40% improvement and the capped annual fee ($132,000). It returned $336,000 a year in value, a 155% ROI, a 4.7 month payback and a three-year net value of $612,000. Its net annual benefit of $204,000 is the table's $17,000 monthly saving times 12. The tool says ROI, payback and three-year value use the annual price and leave out the one-time implementation cost, which it set at an example $19,800. Replace that with what you charge for the pilot, and show it in the year 1 total. Show finance the conservative scenario too: 27% ROI and a 9.4 month payback.

1. Write your outcome as one unit the buyer already counts, plus one guardrail measure.
2. List every way your buyers pay for this work today, and price each one on their volumes.
3. Run the EPIC audit with every optional input. If two motions tie, decide which buyer role each one is for.
4. Draft the mutual action plan, then check the security review order, the pilot length and the holidays.
5. Define resolved in the success metrics section, and get the buyer's QA owner to agree.

If you run an IT services firm

The same chain works for a firm that bills by the hour. Start from work you deliver again and again, so the unit is forecastable. I ran a small version with no company named: IMPACT's value proposition tool, sector ITeS, for a generic claims service priced per claim completed. It said "The CIO, COO or business unit head signs" and will weigh "scope, price model (per FTE, per ticket or fixed), SLA, service credits and exit terms". The proof it says lands: "Service level and cost outcomes at a similar client, with the transition timeline that was actually met."

Then the same offer went into the proposal section writer for a risk mitigation section. It opened with "Typical risks (not from your input)" that read like software risks; delete them. Keep its ITeS risks, in the table alongside, and the commitment "the service level in your contract, and the credit if you miss it": for a services firm, the service credit is where the outcome price lives. My own working rule: keep the rate card only for change requests outside the outcome scope.

1. Pricing an outcome nobody has defined. Write what counts as resolved or completed, and who checks it, before the pilot starts.
2. Running an open-ended pilot. Give it a length, a pass mark per criterion and a decision date.
3. Testing on customer data before security clears it. Clear the review first, or test on redacted tickets.
4. Quoting an example result as proof. A figure only counts when it is your customer's, with the period named.
5. Reading a tied motion score as a mandate. A tiebreak names a lead, not a winner.

• From the Buyer Who Champions You to a Message Sales Will Use: Positioning With IMPACT, CRAFT Content and Revenue Enablement
• How I Pick the Lead B2B Go-To-Market Motion With EPIC, Then Size and Anchor It
• How I Stress-Test a B2B GTM Plan Before the Board Sees It, With a Pre-Mortem and a Bottom-Up Count
• All 15 guides