The first customer needs a report prepared from three folders of records. The second sends a spreadsheet with different names for the same fields. The third wants the report to fit an approval process neither of the first two uses. A founder can call the work a platform, but the daily job still looks like a service.
An AI-assisted service should become software when repeated delivery reveals a stable, valuable process that software can improve at sustainable cost. Some work should remain a service because the inputs, judgment, or customer relationship resist useful standardization. The transition is a decision to be earned through evidence, not a compulsory stage in every business.
This article in The Age of AI Leverage follows that decision. Its document-preparation business is hypothetical. The examples are proposed operating exercises, not a history of a tested Salars venture. Selling outcomes defines the promise; here the question is how much of its delivery can become a maintained product.
Service work is a way to learn the job
Delivering a service exposes the material that a demonstration leaves out. Customers send incomplete files, change their minds, use unfamiliar abbreviations, and ask questions that reveal what the output must accomplish. A person supplying the service can adapt while learning which differences matter.
This flexibility is valuable early. A rigid product built before the workflow is understood may force customers into fields that do not fit their work. A service can ask a follow-up question, inspect an exception, and revise the process without making every uncertainty part of an expensive interface.
The learning must be recorded. If all knowledge remains in the founder’s memory, the service has not created a reusable asset. Keep a concise record of input requirements, accepted outputs, common variations, reasons for escalation, and corrections that changed the procedure.
Distinguish a customer’s preference from a consequential requirement. One wants a blue heading; another needs a reference included because an approval system rejects records without it. Both may matter commercially, but only one changes the core completion condition. A product boundary depends on understanding that difference.
Early manual work should not be concealed. A customer can reasonably buy a useful service with human review. Claiming autonomous delivery while relying on undisclosed people to make every result acceptable creates a false impression of both capability and economics.
Find the repeated decision, not just repeated words
A report template may look similar across clients while the decisions behind it differ. One client needs a summary for discussion; another needs an evidence-linked packet before committing funds. Automating the shared headings does not mean the service’s judgment is standardized.
Follow the decision path. Which inputs determine the output? Which rules are stable? Which questions require a person? Which facts must be current? The recurring relationship between those elements is a better product candidate than a collection of familiar sentences.
For the hypothetical document service, perhaps all clients need the same three checks: correct case identity, required source completeness, and explicit unresolved conflicts. Layout can vary while those checks remain stable. That suggests a reusable core for case preparation with customer-specific presentation.
Another task may resist the transition. A client might ask the provider to interpret a novel commercial dispute. The sources, consequences, and expertise required can change materially from case to case. A model can help organize evidence, but the service should not turn that assistance into a standardized final judgment merely because the output fits a form.
The back-office chapter explains why matching and reconciliation deserve separate roles. Product development should preserve those roles rather than hide them behind a single generate button.
Build a case ledger before a product roadmap
A case ledger records what arrived, what was missing, which actions were taken, total work, corrections, and whether the customer accepted the result. It should contain only the information needed for the delivery and learning purpose, with appropriate authorization.
Group cases by meaningful variation. Document source, output requirement, integration, and exception reason can reveal recurring patterns. “Difficult client” is an unhelpful category when the actual problem was an incompatible export or an omitted field. The grouping should identify a process that could change.
Track provider time and customer time separately. A product may reduce the provider’s assembly effort while increasing the customer’s verification burden. That transfer can improve apparent margins without improving value. The acceptance record should show whether the customer received a genuinely easier result.
Retain failed and abandoned cases. If the ledger contains only accepted work, the proposed product will be designed around success. A source type that repeatedly causes unresolved identity conflicts may need exclusion or a different intake process.
Privacy obligations follow the records through the learning process. Authorized access to deliver a client’s work does not automatically authorize retaining its sensitive material for unrelated product development. The FTC’s business data guidance favors collecting and keeping sensitive information only when there is a legitimate need. FTC guidance.
Use the common core carefully
The common core consists of behavior that several appropriate customers need and that the provider can maintain consistently. It might include file validation, stable references, evidence extraction, rule checks, review packets, and action logs. These functions can exist without an elaborate new platform.
Start by codifying the least ambiguous pieces. An ordinary script can verify required fields or calculate a total. A saved process can create a packet from approved sources. A model can draft a summary whose claims remain linked to those sources. The repeated knowledge into software article explains this decomposition.
Keep customer-specific rules in an explicit configuration layer where possible. A required field or an approval destination can be configured. A complex interpretive judgment should not be disguised as a setting merely to claim every customer fits the same product.
Version the core and the customer configuration. When a rule changes, identify which cases were prepared under the earlier version and whether they need review. A service that cannot explain which procedure produced an output will struggle to maintain reliability as its customer base grows.
Do not standardize by deleting necessary differences. If one client’s process requires a different evidence threshold, the product must support that threshold or exclude the client. Convenience for the provider is not a sufficient reason to flatten the customer’s responsibility.
Measure the exception burden
A product can appear efficient when most cases complete quickly, while a small share consumes much of the labor. Inspect the tail of the workload. The rate, severity, and resolution time of exceptions determine how much software-like scale the business really has.
Suppose, in an invented monthly example, 100 cases require five minutes each when routine. Eighty cases fit that route, using 400 minutes. Twenty require an additional twenty minutes each beyond the routine preparation, using another 400 minutes. Including the twenty exception cases’ first five minutes, total work is 400 + 100 + 400 = 900 minutes, or fifteen hours.
If a founder reports only the routine five-minute process, the implied total is 500 minutes. That omits 400 minutes of exception effort. Improving the routine route to three minutes would save 200 minutes, but resolving the cause of half the extra exception burden could save the same amount. The example is arithmetic, not an observed efficiency study.
Some exceptions are temporary onboarding issues. Others are structural variation that every new customer brings. Record which is which. A one-time mapping exercise can justify an integration fee; recurring professional judgment needs a continuing service price and appropriate capability.
A product need not eliminate every exception. It must make the remaining work recognizable, owned, and economically supportable. Customers may happily pay for a hybrid that handles routine preparation well and provides responsible review when the case becomes difficult.
Avoid confusing revenue with product economics
A service can sell for a price that supports its labor while being unattractive as a broad software product. A product can have a low processing cost while needing costly onboarding, acquisition, support, and maintenance. Compare the whole business rather than a single delivery action.
For the hypothetical service, an invented client pays $600 per month. Direct recurring delivery requires six provider hours valued at $40 per hour, or $240, plus $60 of specified tools and processing. That leaves $300 before acquisition expense, other overhead, taxes, and unexpected work. The planning value of labor is explicitly assumed.
If software reduces delivery to two hours but adds $150 of allocated maintenance and support, the defined recurring costs become $80 plus $60 plus $150, or $290. The difference is only $10 under the stated boundary. Automation that appears dramatic at the task level barely changes the comparison.
If the product also requires a large development investment, the founder needs a realistic account of how many appropriate customers can be served and retained. Avoid treating a hopeful customer count as an established market. The first few buyers are evidence about those buyers.
Pricing can preserve the distinction. A setup fee covers known onboarding work. A recurring fee covers maintained capacity. Additional service work can be priced explicitly when it falls outside the standard scope. A clear hybrid is preferable to a cheap subscription whose sustainability depends on unpaid labor.
Choose a reversible first product
The first product can be an internal tool used by the service team. That allows the provider to test whether a repeatable process actually reduces effort before asking customers to adopt a new interface. It also makes the remaining human work visible.
For example, the document service could create a standard intake check and review packet. Staff compare its output with the existing process and record defects. The tool assists delivery without yet changing the customer contract or gaining permission to send final work.
A customer-facing version can follow when the boundary is clearer. Perhaps customers upload approved files, see missing fields, and review prepared packets. The interface should expose uncertainty and responsibility, rather than make an incomplete result look complete.
Keep an export and a manual fallback. If a product becomes unavailable, the service should still locate open cases and the authorized evidence. A customer should not lose control of its own work because the provider chose a new interface.
Migration should proceed with a small appropriate scope. Moving every client at once can convert one product defect into many failures. Preserve the earlier process until the new one has demonstrated reliable behavior on the relevant cases.
Agree on migration acceptance before asking a client to switch. Identify which outputs must match, which changes improve the process, and which defects require reverting. An internal tool can be useful without being ready for customer self-service. Customer training, accessible instructions, support ownership, and a usable correction route are separate requirements.
Keep unfinished cases on a known path during the transition. If an old case moves into the new product, preserve its earlier decisions and source references. A new identifier should not erase an unresolved commitment. Decide who checks the transition and how duplicate work will be prevented. These details rarely appear in a product demonstration, but they determine whether the customer can adopt the change without carrying an unexplained new burden.
Some services should remain services
A high-variation task may derive much of its value from judgment, explanation, or relationship. Software can still support the provider, but forcing the final delivery into self-service may weaken the outcome. The service can remain viable if the price and capacity fit its labor.
A customer may want a person to interpret the packet’s unresolved issues and explain the options. That conversation is part of the value. A interface that generates another report may not replace it, even if the report is accurate.
Another customer may use the service only occasionally. Learning a new product and maintaining an integration can cost more than handing the task to a provider when needed. A service can be the lower-friction route for low-frequency work.
There are also cases where professional responsibility or consequences require qualified human involvement. The correct response is to preserve that role and use assistance within its boundaries. A founder should not treat required review as a temporary inconvenience that scale will eventually remove.
The decision is therefore not service versus software as a hierarchy of prestige. It is which arrangement gives the customer accepted work and gives the provider sustainable delivery. Internal software, customer software, managed service, and a hybrid can each fit different portions of the same workflow.
Watch how incentives change during the transition
A service team hears customer problems directly. A software team may receive simplified metrics and support tickets. Productization can improve consistency while reducing the provider’s understanding of how the work is actually used. Preserve a route for consequential feedback.
If the product rewards completed cases, it may encourage users to skip missing evidence. If pricing penalizes exceptions too heavily, customers may avoid flagging them. If the provider promotes automatic completion as its central benefit, staff may feel pressure to reduce necessary escalations.
Set the measures accordingly. Track accepted work, customer burden, correction cost, unresolved cases, and consequential errors. Review a sample of apparently successful cases. A quiet wrong answer can look better in the product dashboard than an honest request for review.
Staff expertise needs deliberate maintenance. As routine work is automated, people may encounter fewer examples through which they learned the process. Use appropriate training and retained cases to keep reviewers capable of recognizing unusual failures. An approval gate relies on a reviewer who understands what approval means.
These are proposed operating considerations, not claims that every product transition causes the same behavior. Their value is to identify plausible failure paths before a business becomes dependent on the new arrangement.
AI Leverage in Practice
What changed? AI can help a small service codify portions of reading, preparation, and drafting that previously required sustained manual effort. The repeated core may become easier to build, while customer variation and responsibility remain.
What can you do today? Keep a case ledger, classify recurring requirements and exceptions, and measure total provider and customer effort. Build a small internal tool around the stable core. Compare accepted outputs and costs before promising a self-service product.
What becomes possible later? A tested common core may support more customers with less incremental labor, or become a customer-facing product. Expansion depends on maintained rules, appropriate data use, integration, and a viable support model. Some interpretive work may rightly remain a service indefinitely.
Let delivery reveal the product
The three hypothetical customers do not necessarily need the same interface. They may need the same reliable identity check, a different required field, and a person who understands why one case cannot proceed. A useful product preserves those relationships.
Service first gives the founder an opportunity to see them. Software later can make the stable portions easier to repeat. The transition works when the customer receives a better route to accepted work and the provider can support that route honestly.
Explore the AI section, or return to the series hub.
Sources
- FTC, Protecting Personal Information: A Guide for Business, checked October 7, 2026.
- Turn Repeated Knowledge Into Software.
- Back-office AI workflows.
All customer arrangements, quantities, and prices above are hypothetical. They demonstrate decision boundaries and arithmetic, not a commercial return forecast.
Loading comments…