A team can make an impressive AI prototype and still have nothing new to sell. It has demonstrated a capability. The customer has not yet been given a reason to pay for it.
That distinction matters when an investment proposal promises new revenue. Faster internal work may improve margin or release capacity. Revenue requires another decision: what useful outcome can the business now offer, to whom, and on terms that make sense for both sides?
I would start with work the company has previously declined. Small orders that required too much preparation. Customers who needed advice more frequently than they could afford it. Problems that were worth solving but never large enough to justify the delivery cost. An AI capability becomes commercially interesting when it changes one of those limits.
Look for an offer that used to be uneconomic
The OECD’s late-2024 survey of 5,232 SMEs in seven countries, published in 2025 as Generative AI and the SME Workforce, captures the distance between better work and more sales. Among SMEs using generative AI, 65% said it helped increase employee performance, while 26% said it helped increase revenue. These are reported outcomes, rather than evidence that AI alone caused them.
The commercial question for your company is more specific. Which customer need becomes affordable to serve if part of the work takes less effort?
Consider a hypothetical industrial equipment supplier. Customers send it warranty claims, service notes and photographs. The supplier helps with individual failures, but reviewing a customer’s accumulated records takes enough specialist time that only large accounts can justify it.
Suppose AI can organize the records, identify repeated descriptions and prepare a traceable set of cases for an engineer to review. That could make a periodic reliability review viable for smaller accounts. The customer would get help deciding which recurring faults deserve investigation and which maintenance practices need attention.
The opportunity depends on the complete job becoming cheaper. If every batch requires hours of data repair and every apparent pattern needs extensive correction, the attractive demonstration has concealed an expensive service.
Sell the decision the customer can make
A report is easy to produce and easy to ignore. Before designing a subscription, establish what the customer would do differently with the information.
In the equipment example, the useful result might be a prioritized investigation list for the next maintenance meeting. The person buying the service needs to understand what that list changes: which issue gets attention first, what evidence supports it and what further work is required before acting.
Several people may have a say. The maintenance manager needs technically credible findings. The owner wants the fee to be justified. The colleague exporting service records wants a manageable request rather than another monthly administrative burden.
An offer that works for only one of them may never get purchased, or may disappear after the first delivery.
Ask what already happens when the problem arises. If the customer knows the recurring faults but has no budget to address them, more analysis may add little. If its existing maintenance system already produces the required view, the missing ingredient could be time or expertise to use it. Both discoveries should change the offer before you build anything.
A paid service can be the first useful experiment
You do not need a finished software product to test whether customers will buy an outcome. A bounded service can provide better evidence while leaving more room to change direction.
In this hypothetical service, the first engagement could cover one equipment group, one defined period and an agreed set of records. State what will be delivered, who reviews it, when the customer receives it and what falls outside the assessment. The conditions for handling customer information must already be in place.
Payment tells you more than enthusiasm after a demonstration. It still leaves questions unanswered. One customer might have an exceptional problem, or buy because of an existing relationship. The next few engagements should test whether others want substantially the same result on similar terms.
After delivery, find out what was used. Which finding prompted an investigation? Which section was ignored? What did the customer still have to work out? Those answers are more useful for the next product decision than a request for additional dashboard features.
A safe sample can establish technical feasibility before a paid engagement. Customer operations should never become the test environment for unresolved access, data-handling or review arrangements.
Find the labor that the demo leaves out
A low model bill can make a service look profitable while the people doing the work subsidize it.
Someone requests missing records, reconciles equipment names, checks source material, revises the assessment and answers follow-up questions. A difficult batch may take longer than all the clean ones combined. Founder time belongs in that calculation even when no payroll entry makes it visible.
For an ordinary customer in this hypothetical service, suppose a $600 review takes half an hour to request records, one hour to clean them, two hours for engineering review and corrections, and half an hour for follow-up. At an assumed fully loaded labor cost of $75 an hour, those four hours cost $300. Allow another $20 for software and infrastructure, and $280 remains to cover acquisition, development and general expenses before profit. Two extra hours of cleanup would cut that contribution to $130.
The actual price and effort need to come from complete deliveries. Measure preparation, review, correction and support alongside software and infrastructure costs. A clean demonstration cannot tell you what an ordinary account will cost to serve.
Differences between customers matter. If the service only works economically with well-structured records, make that an entry condition or price the cleanup separately. An unlimited promise to accommodate every format can consume the benefit you hoped to gain.
Also examine what the new sale replaces. Existing customers may switch from a larger engagement to a cheaper recurring package. That can be a sound move if it releases valuable capacity or improves retention. It does mean that the new product’s revenue cannot all be counted as additional revenue. Compare the whole account before and after the change.
Your advantage has to survive access to the same model
The customer can buy an AI tool too. So can the next supplier. A commercial case that depends only on generating a document faster is exposed to that comparison.
The supplier in this illustration might earn its fee through knowledge of the installed machinery, the quality of its engineering judgment and its ability to follow up on earlier interventions. The customer also benefits from a clear handover and evidence that can be checked when a conclusion is disputed.
Those are delivery obligations. Calling an output “expert reviewed” creates an expectation that someone actually compared the findings with the records and judged their significance.
Custom software may eventually help the supplier meet those obligations efficiently. I would invest once repeated deliveries expose a specific constraint worth removing: recurring data preparation, a review queue or an integration that consumes time on every account. By then, the company has evidence about what the system needs to do.
Let the next purchase tell you what to build
A recurring fee needs recurring value. If little changes from month to month, a quarterly review or an assessment triggered by a particular event may suit the customer better. The billing schedule should follow the useful work.
Repeated orders can also reveal a different business. Customers may pay mainly to get their records into usable shape, or want help implementing the recommendations. That is valuable information, even if it invalidates the original subscription idea.
Before approving the next development budget, put a short offer beside the proposal. Name the buyer, the result, the delivery conditions, the price and the full cost of serving an ordinary customer. Add what the first purchases have taught you and which uncertainty the proposed development will resolve.
If those details are still assumptions, the next investment should help test them. If customers buy, use and request the result again at a workable margin, you have a reason to make delivery more reliable and less expensive. That is a much firmer brief for development than “build us an AI product.”