A business can become faster without becoming better. It can answer more inquiries, send more proposals, accept more orders, and consume its remaining cash at greater speed. Automation removes friction from the process it is given. If the process reliably creates a loss, removing friction can increase that loss.
The warning is easy to state and harder to apply because an apparently struggling business may contain a useful offer buried under poor operations. Automation could help that business. Another firm may have excellent operations and a product customers do not value at a sustainable price. The same tool can improve the first and accelerate the failure of the second.
Before choosing an automation project, diagnose which problem the business has. Does each accepted sale create enough contribution to support the work and obligations around it? Is there real demand? Can the business deliver the promise? Is cash arriving soon enough to sustain delivery? Is the apparent inefficiency a removable cost or a necessary act of judgment?
These questions keep the technology attached to the business it is supposed to serve. A capable model is not a substitute for an offer that deserves to exist.
Growth can amplify negative economics
Consider a hypothetical service that charges $100 per job. Direct delivery, review, and support cost $80. Acquiring the customer costs another $30. Before fixed overhead, the first transaction loses $10.
An assistant doubles the number of proposals the business can prepare. If conversion and costs remain the same, more accepted jobs create more loss. The operator may feel successful because the calendar fills and the revenue graph rises. The bank balance tells a different story.
There are several ways the economics could improve. Acquisition expense might fall. Customers might return at lower acquisition cost. The offer might support a higher price. Delivery might become less costly without reducing quality. The business might narrow its scope to work it can perform efficiently. Each possibility is a hypothesis requiring evidence, not a reason to assume growth is already profitable.
The first task is to identify the loss at the relevant unit. A broad monthly total can conceal a valuable product family subsidizing a weak one. A convenient average can hide customers who require extensive support. A more precise view does not need elaborate software; it needs records connecting the sale to the work it creates.
A task saving is not necessarily a business saving
Suppose AI cuts proposal drafting from an hour to fifteen minutes. That is a task-level improvement if quality holds. Whether the business benefits depends on what happens to the saved time and what new costs appear.
If the owner uses the time to serve an already profitable backlog, the change may create useful capacity. If the owner produces proposals for buyers who rarely convert, the improvement may create a larger pile of unpaid work. If review now takes longer, the net saving may be smaller than the drafting result suggests.
The distinction matters because tasks are often measured where the tool looks strongest. Generated text is easy to count. The expense of correcting an inaccurate promise may appear later in customer service, refunds, or the owner’s evening. A business evaluation must follow the task through to an accepted result.
The AI leverage equation frames the wider relationship. This article’s concern is the starting business: which activity is worth accelerating, and which should be redesigned or abandoned before automation expands it?
Demand is separate from production capacity
AI can make it easier to create a service offer, website, guide, software prototype, or product catalog. It cannot establish that customers want those things at the price required to sustain them.
A hypothetical business may build a sophisticated report that helps small firms compare vendors. The report may be accurate and useful. Customers may still prefer a brief phone call because their buying decision is infrequent, local, and based on relationships. The production system can work while the offer fails.
Investigate the customer’s existing behavior. What problem do they pay to solve? What do they tolerate rather than buy a remedy for? Who authorizes spending? How often does the need recur? What evidence would make them trust a new provider? A model can help organize interviews or compare answers, but the evidence comes from real responses and transactions.
The SBA’s business-planning guidance separates market research, competition, costs, and funding. That separation is useful here: a cheaper production method answers one part of the plan, not the whole plan. SBA, Plan Your Business.
A paid, narrowly scoped pilot may reveal more than a fully automated launch. It can show whether the customer values the result, what delivery actually requires, and which exceptions recur. Label a pilot as a pilot and preserve the records needed to learn from it.
The offer may contain an impossible promise
Some businesses fail because they promise an outcome they do not control. A seller guarantees carrier delivery without controlling the carrier. A service guarantees recovered revenue without knowing the quality of the underlying claims. A consultant promises a sales result that depends on a client’s inventory, pricing, and follow-through.
Automation can multiply these promises. It can send confident commitments to more people, accept work before capacity is checked, or turn an internal estimate into a customer guarantee. The resulting growth creates obligations the firm cannot reliably meet.
The correction is to identify what the business controls and price the remaining uncertainty. The seller can promise a verified dispatch process while accurately explaining delivery estimates. The service can define eligible cases and fees without guaranteeing recovery. The consultant can promise specific work and a measurement plan rather than a fabricated outcome.
This is a business-design problem before it is a model problem. Approved language helps, but the underlying service must be deliverable. Trust capital explains why a smaller credible promise can support a better relationship than a larger claim the firm repeatedly fails to fulfill.
Cash can fail while margins appear healthy
A business may have positive contribution on paper and still run out of cash. It pays suppliers before customers pay, holds inventory too long, or expands faster than its working capital supports.
Imagine a hypothetical distributor that pays for stock at order placement, waits for shipment, sells on credit, and collects later. Faster purchasing recommendations can increase the amount of money committed before sales produce cash. If automation also accelerates accepted customer orders, the firm may need more inventory and fulfillment spending immediately.
The key dates are cash leaving, stock becoming available, the customer buying, and usable payment arriving. A model’s projected revenue does not shorten those intervals by itself. The operator must understand the actual cycle and the reserve needed to withstand delays.
Capital velocity examines that timing in detail. At the diagnostic stage, ask whether the business can fund the work automation will create. A profitable offer with insufficient financing needs a different response from an unprofitable offer with a large cash reserve.
Some friction performs a useful job
It is tempting to automate whatever feels slow. Yet a slow step may prevent a costly mistake. Checking a buyer’s specifications, inspecting a used item, obtaining consent, or approving an unusual obligation can add time while protecting the transaction.
A hypothetical supplier may require a technician to review compatibility before accepting a special order. Removing that review increases throughput. It may also increase wrong orders and disputes. The apparent inefficiency was part of the service’s value.
This does not mean every old process is necessary. The question is what the step accomplishes. Could a better record, clearer form, or reliable rule provide the same protection at lower cost? Could ordinary cases proceed automatically while uncertain cases receive review? Could the business reduce ambiguity earlier so less judgment is needed later?
Automating normality and escalating exceptions addresses that operating design. The business diagnosis comes first: identify the protection the friction supplies before removing it.
The wrong objective can improve beautifully
An automated system follows the objective and feedback it receives. If the business rewards more leads, the system may produce more low-quality leads. If it rewards faster responses, it may provide premature answers. If it rewards revenue, it may favor products with weak contribution or costly returns.
The metric can improve while the business deteriorates. That is possible even without malicious behavior or a dramatic hallucination. The system may be doing exactly what the operator asked.
A better objective connects the activity to accepted value. Qualified inquiries matter more than total inquiries when sales attention is scarce. Accurate resolution matters more than response speed when wrong answers create obligations. Contribution and cash timing matter alongside sales.
No single metric captures every important consequence. Pair the principal measure with guardrails: complaint rate, rework, cash exposure, service quality, and prohibited actions where relevant. A guardrail is useful only if someone can act when it is crossed. A dashboard that reports damage after the firm has spent all its reserve is not an adequate control.
Diagnose the business in a specific order
Start with the buyer and the job. A clear description prevents the analysis from drifting into generic advice. Then examine demand, delivery, unit contribution, cash timing, and responsibility for exceptions.
A short diagnostic can use five questions:
- What result does the customer actually buy, and what counts as accepted delivery?
- Which evidence shows that appropriate customers want it at the proposed price?
- What direct work, acquisition, review, remedy, and support does one transaction require?
- When does cash leave and when does usable cash return?
- Which cases should be refused, revised, or escalated before acceptance?
The questions are connected. Narrowing the offer may improve delivery and contribution while reducing demand. Raising price may cover costs and reduce conversion. Changing payment terms may improve cash and make the offer less attractive. The purpose is to expose these tradeoffs, not discover a painless answer to all of them.
Once the business is understood, select the automation that addresses its real constraint. If the constraint is missing demand, faster back-office work may be useful but will not fix it. If the constraint is avoidable re-entry of verified records, an ordinary integration may help more than an autonomous agent.
Compare improvement with redesign and stopping
An automation proposal should have alternatives. Keep the current process, simplify the offer, change the price, reduce scope, outsource a narrow task, use conventional software, or stop the activity. These alternatives help determine whether AI is the best use of attention.
A hypothetical firm spending heavily to automate custom reports might instead standardize the report and reduce the number of exceptions. The standardization could create most of the saving while keeping quality easier to inspect. AI may still help, but the economic improvement comes partly from redesign.
Stopping is also a legitimate business decision. An offer that consistently consumes cash, harms trust, and produces little useful learning may not deserve another tool. A kill engine makes stopping criteria explicit before the project gathers advocates and sunk costs.
Be careful with premature stopping too. A valuable new service can have initial setup costs and uncertain demand. The appropriate response is a bounded test with a defined learning objective, not an immediate demand that every first transaction cover all development expense. The business must distinguish investment in learning from indefinite subsidy of a bad offer.
A pilot should test the bottleneck
A good pilot answers a decision. If proposal preparation is the alleged constraint, compare the complete proposal-to-delivery path. Record preparation time, review time, accuracy, qualified acceptance, and the work created by accepted jobs.
Keep ordinary and difficult cases visible. A pilot containing only clean inputs may establish that the tool handles clean inputs. It does not establish readiness for the cases the business actually receives. Preserve a small set of exceptions that were not used to tune the workflow and examine performance there.
Avoid changing the offer, price, channel, and automation simultaneously when the goal is to understand one mechanism. Sometimes a bundled change is the only practical choice; then describe the result as a result of the bundle and keep causal claims narrow.
The test should have a budget, duration, stop condition, and responsible owner. Write down what would count as useful improvement before looking at the favorable cases. These are proposed methods for a reader’s business, not claims that Salars has already performed the experiments.
Automation risk is an operating cost
An assistant that can draft a document has a different loss potential from one that can change prices, send commitments, or spend money. The business should count the cost of permissions, monitoring, recovery, and mistakes alongside the expected saving.
OWASP’s versioned guidance on excessive agency identifies excessive functionality, permissions, and autonomy as distinct sources of damaging actions. A business can reduce exposure by giving a system only the capabilities required for its task and enforcing authority in the connected systems. This guidance does not guarantee that every failure is prevented. OWASP LLM06:2025.
The economic implication is straightforward. If the supposed saving requires broad authority that creates unacceptable loss exposure, the proposal is incomplete. A narrower workflow may be slower and more valuable. Permission architecture provides the technical home for that design; here it belongs in the business case as a real cost and constraint.
AI Leverage in Practice
What changed: ordinary cognitive tasks can be accelerated and connected to digital action. A business can increase throughput before understanding whether the throughput is worth buying.
What to do today: choose one proposed automation and trace the customer result all the way through payment, delivery, support, and remedy. Use actual records where available. Separate known costs from estimates and mark missing information explicitly.
Compare automation with one simpler redesign and with continuing the current process. Give any pilot a defined budget and completion question. If the offer fails demand, contribution, deliverability, or cash requirements, address that failure before increasing volume.
What may come later: more reliable agents may reduce coordination costs and open new offers. They will still operate inside a business with customers, obligations, and scarce resources. Improved tools cannot make an unwanted or impossible promise economically sound by performing it more enthusiastically.
Speed in a worthwhile direction
AI can help a weak business when the weakness is a task it can improve. It can damage the same business when it accelerates loss, overcommitment, or an objective detached from customer value.
The difference is visible before the automation becomes elaborate. Define the offer. Follow the costs. Check the cash. Understand the exceptions. Identify what the slow step was protecting. Then decide which work deserves to become faster.
A business that knows why a transaction is worthwhile has a meaningful place to apply leverage. A business that does not may simply reach its next problem sooner.
Read the complete Age of AI Leverage series or explore the wider AI section.
Sources
- SBA, Plan Your Business, market research, competition, costs, and funding.
- OWASP, LLM06:2025 Excessive Agency, versioned security guidance for systems able to act.
Loading comments…