A business owner does not wake up hoping to acquire another model subscription. The owner may need an approved estimate ready before a customer leaves, a backlog of records resolved, or a reliable answer to a question that keeps interrupting the work. Intelligence has commercial value when it helps produce that result at a cost the customer can justify.
An AI-assisted business should sell an outcome it can define, deliver, and verify. That does not require charging only when a result occurs. It means the offer begins with the customer’s problem, explains the boundary of the service, and makes its performance inspectable. Model access is one input. The thing being bought is useful work and a responsible way to handle work that cannot be completed.
This chapter of The Age of AI Leverage examines the contract between capability and value. The AI leverage equation describes why cheaper cognitive work may matter. Here the question becomes practical: which portion of that potential can a customer actually purchase?
Begin with the unfinished job
Consider a hypothetical facilities contractor. Its technicians inspect equipment and leave photographs, notes, and measurements. Before a client can approve the next stage, someone must assemble a clear inspection packet, identify missing fields, and connect each observation to the correct site and visit. The backlog creates delays even though the inspections themselves are complete.
An offer to provide an AI dashboard gives the contractor another interface. An offer to prepare review-ready inspection packets addresses the unfinished job. The service could organize approved records, draft summaries, flag conflicts, and route uncertain cases to the technician. A qualified person would still approve technical conclusions and customer commitments. These are proposed functions, not evidence of a deployed service or reported financial results.
The distinction changes the initial conversation. Instead of asking which model the owner prefers, the provider asks what makes a packet acceptable, how the current backlog is counted, who can resolve missing facts, and when a packet matters. A beautifully written summary has little value if it describes the wrong visit. The outcome must include the relationship between the words and the work.
Look for a job that recurs often enough to support a service, causes a recognizable problem, and has a credible completion condition. Recurrence alone is insufficient. An owner may repeat a task because it takes only a minute or because the personal conversation itself carries value. Removing that task could save negligible cost while damaging the relationship.
The strongest starting point is a documented bottleneck with an owner who wants it resolved. A vague desire to become more modern is harder to serve. It has no natural baseline, no clear finish, and no agreed reason to pay again next month.
Define the result before naming the technology
A useful outcome definition identifies the unit of work, its eligibility conditions, the acceptance test, and the time boundary. For the hypothetical contractor, the unit is one inspection packet for one authorized visit. Eligibility requires a matching job record, approved source material, and sufficient identification. Acceptance requires correctly organized evidence, required fields, and explicit unresolved questions.
“More efficient operations” is too broad to be the deliverable. “A review-ready packet within the agreed interval after complete source material arrives” is inspectable. The provider can record whether the packet met the stated requirements, whether it needed correction, and which delays belonged to missing inputs rather than the assembly process.
The customer should be able to reject defective work for a reason that both parties understand. A contract that counts every generated document as complete rewards production regardless of usefulness. A contract that allows rejection for any subjective reason places unlimited risk on the provider. The practical middle is a written acceptance procedure with examples of acceptable work and consequential failures.
A packet with an omitted page is different from a packet awaiting a technician’s judgment. Treat those states differently. One is a service defect; the other may be an appropriate escalation. If the service cannot distinguish them, its completion metric will reward guessing when it should request evidence.
Define exclusions too. An assembly service does not automatically provide an engineering certification, legal opinion, or guarantee that a repair will succeed. Those boundaries should appear where the customer decides whether the service fits, rather than in a buried disclaimer after the provider has implied comprehensive responsibility.
Why cheaper intelligence does not remove delivery cost
AI can reduce the effort of turning unstructured records into drafts or suggested categories. The provider still needs authorized access, integration, review, correction, customer support, and a method for identifying failures. Those costs determine whether a service is viable.
A draft that takes seconds to generate may require ten minutes to verify. A cheap extraction may fail on the records that dominate a particular customer’s workload. An integration may take much longer than expected because each branch uses a different identifier. The relevant unit cost includes the whole route from input to accepted output.
The evidence for useful assistance is real but specific. In Generative AI at Work, the authors studied a conversational assistant for customer-support agents and found heterogeneous productivity effects. Humans retained responsibility for the conversation. This is evidence about one supported workflow, not proof that a new service will create the same revenue or margin. Author paper.
That boundary matters when estimating value. The study cannot establish what the contractor would pay for an inspection packet. It can support investigating whether assistance helps people perform a defined task. The business still needs local evidence about its sources, error consequences, review time, and willingness to buy.
Compare AI with a simpler alternative. A well-designed form, naming convention, checklist, or ordinary script may remove the bottleneck more cheaply. Selling outcomes gives the provider permission to choose that solution. Selling AI as the identity of the offer can create pressure to insert a model even when it adds little.
Work through a proposed price
Suppose the hypothetical contractor currently spends twelve minutes assembling each eligible packet. For a planning exercise, it values that work at $30 per hour. The implied assembly cost is $6 per packet. These invented figures illustrate a calculation; they are not measured labor costs, market prices, or expected returns.
Now suppose a proposed assisted service charges $3 per accepted packet and requires three minutes of the contractor’s review time. At the same planning value, review adds $1.50. The direct comparison is $6 against $4.50, a possible difference of $1.50 before other effects. If review actually takes seven minutes, customer cost becomes $6.50. The apparently inexpensive service becomes more expensive under the stated assumptions.
For the provider, the $3 receipt is not profit. Assume $0.15 of model and processing expense, $0.35 of allocated operating tools, and five minutes of provider labor valued at $24 per hour, or $2. Those assumptions leave $0.50 before sales expense, overhead, rework, and taxes. The proposal may be useful to the customer and unattractive to the provider.
The point of this exercise is the sensitivity. Review time and exception rate can matter more than inference cost. A change in the model bill of a few cents cannot rescue a process that needs sustained manual attention on every unit. Conversely, a better intake form may improve the economics without any model improvement.
The provider should show the customer which costs the fee includes and which remain with the customer. A service that shifts verification work onto the buyer while presenting only its own efficiency creates a misleading comparison. Both sides need to understand the retained burden.
Select a pricing model that matches control
A fixed project fee suits an outcome with a bounded scope, such as clearing an identified backlog after an initial assessment. A recurring fee can support maintained capacity, monitoring, and a defined service level. Per-unit pricing suits comparable units with visible acceptance conditions. A hybrid can cover fixed integration costs while charging for variable delivery.
Outcome-contingent pricing, in which payment depends on a downstream result, requires extra care. The provider may not control that result. An assembled packet may reach an approval queue, but the client can still reject the underlying repair, postpone spending, or change plans. Tying all payment to approval transfers risks that have little to do with document assembly.
A fee tied to recovered money or new sales also raises attribution questions. Would the invoice have been paid without the service? Did a discount increase order count while reducing contribution? Did the customer acquire more leads through another campaign? The revenue recovery chapter develops those distinctions.
Do not assume performance pricing is inherently more honest. It can reward pressure, premature classification, or selective reporting when the result is poorly defined. A conventional fee with transparent acceptance records may align incentives better than a dramatic promise to get paid only on success.
The appropriate arrangement shares risk according to what each party can observe and influence. The customer supplies usable records and timely decisions. The provider delivers the agreed work and maintains the system. Neither side should pretend it controls all future consequences.
Count acquisition and retention
A service can earn a positive margin on each delivered unit and still fail because finding customers costs too much. Sales conversations, demonstrations, security reviews, trial setup, travel, and integration preparation consume resources. Include failed prospects rather than assigning all sales effort to the few people who buy.
In an invented example, ten prospects require a combined twenty hours of work and $200 of other acquisition expense. At a $30 planning value per hour, total acquisition cost is $800. If two become customers, acquisition cost is $400 per customer under that allocation. A $50 monthly contribution would need eight months merely to recover that amount, assuming no churn or additional expenses.
That arithmetic is a warning against quoting a subscription price and declaring a software-like business. The provider needs to know how long customers remain, how quickly they become useful accounts, and what maintenance consumes. A buyer who renews because the service is indispensable may support substantial integration. A buyer who occasionally wants a cheap draft may not.
Customer acquisition cost is also uncertain early on. A founder’s personal relationships can produce low apparent cost that will not transfer to another salesperson. An unusually enthusiastic first customer may tolerate manual intervention that later buyers reject. Keep early observations scoped to the actual circumstances.
Retention depends on continued usefulness. If the service helps the contractor eliminate its backlog and improve its own intake process, the original demand may shrink. That is a good customer outcome, but the provider needs an honest next role or a planned end to the engagement. Manufacturing new dependency is a poor substitute for a viable business model.
Make responsibility part of the product
The person paying for an outcome needs to know what happens when a source conflicts, a tool fails, or a mistaken document reaches a client. A useful service includes ownership of these situations. The provider should be reachable and capable of tracing the affected work.
For the contractor, each packet could carry a job reference, the source versions used, the responsible reviewer, and its current state. If a technician corrects a measurement, the service should identify which draft depended on the earlier value. Producing a new packet without finding the old version leaves both circulating.
Access should follow the work’s actual requirements. An assembly service may need inspection records without needing payroll, every customer’s history, or payment authority. The FTC’s business data guidance recommends collecting and retaining sensitive information only for legitimate needs and restricting access. FTC guidance.
The technical boundary belongs in the tools too. A drafting account should not be able to send customer messages merely because the written prompt says to ask first. The agent permission architecture explains how to separate recommendations from consequential actions.
Responsibility also covers the cost of correction. Agree which failures require rework, when credits apply, and who handles communication with affected customers. These terms can be modest and proportionate. Their purpose is to make a mistake manageable rather than leave everyone arguing about whose automation caused it.
A service agreement should also identify an orderly exit. The customer needs an export of its authorized records in a usable form, a list of unresolved cases, and a clear end to the provider’s access. A cancellation that strands open work can turn a short engagement into a continuing liability. Price the closing effort when it is material, and make data return or deletion consistent with the parties’ responsibilities. The outcome includes handing the work back well when the engagement ends.
Learn what buyers refuse
Before building a broad platform, inspect actual buying objections. A contractor may reject the service because its clients require a particular approved format. Another may need offline operation. A third may have too little volume to justify setup. These are different problems, and only some are worth solving.
A refusal can reveal the real unit of value. Perhaps packet assembly is easy, but finding missing technician notes is painful. Perhaps clients already accept an existing system and want fewer interfaces. Perhaps the owner fears losing control of technical statements. A proposed product should change when the evidence identifies a different bottleneck.
Avoid treating every objection as a sales challenge. Sometimes the customer is explaining that the service does not fit. Persuading an unsuitable customer to buy produces support work, disputed value, and likely churn. A clear exclusion can be economically useful.
The vertical AI chapter examines how these observations help define a narrow market. Specialization becomes valuable when it improves completion of a particular job. It becomes decorative when it merely replaces a generic dashboard’s industry label.
AI Leverage in Practice
What changed? Some of the reading, organizing, and drafting inside a service can be performed with less effort. That changes the feasible delivery process, while acceptance, integration, judgment, and customer responsibility remain substantial work.
What can you do today? Choose one unfinished customer job and write a one-page offer. Specify eligible inputs, the accepted output, a baseline, retained customer work, exclusions, price, and the failure path. Process a small authorized sample in draft mode. Compare full time and error cost with the existing method. Do not claim a commercial result until a real customer has accepted the relevant work.
What becomes possible later? If repeated delivery demonstrates a stable process, more of it may be codified and sold at lower marginal cost. Broader autonomy requires evidence that the service can recognize exceptions and preserve obligations. A provider might eventually support a larger volume without proportionally larger staffing; that is a conditional possibility, not an income forecast.
A result the customer can inspect
The real business opportunity is the distance between work a customer needs and work the customer can reliably obtain. AI may shorten that distance, but it cannot define value on the customer’s behalf. The provider must identify the job, carry it through its exceptions, and make the outcome visible.
For the hypothetical contractor, success is a packet that reaches the proper reviewer with the right evidence and unresolved questions clearly marked. The model matters because it may help assemble that packet. The purchase makes sense because the packet helps the contractor move legitimate work forward.
Return to the AI section for related tools and investigations, or continue through the series hub.
Sources
- Brynjolfsson, Li, and Raymond, Generative AI at Work, author paper. One customer-support setting; results are not a universal service-return estimate.
- FTC, Protecting Personal Information: A Guide for Business. Current guidance checked October 7, 2026.
- Revenue recovery and attribution.
- Service first, software later.
Loading comments…