A company buys software the way it buys a machine. It is specified, paid for, installed and depreciated, and if it works on day one it is expected to work on day nine hundred with maintenance. That model served the recording era well, because a database with a form on it is a machine. It is failing the acting era, and the failure shows up at the renewal, when a company discovers it has paid a year for agents that ran for a month.
The reason is not the software. It is that the shift from recording to acting is not a thing you can own. It is a condition you keep.
An agent acts on records under rules inside a boundary and leaves a trail. Each of those four things moves.
The records drift. New products, renamed fields, a rep who stops filling in the industry, a migration that left two versions of three hundred customers. An agent that was right against the records of January is acting on different records by June, and nobody changed the agent. We have written about what thin records do to anything that reasons over them in what changes when the system acts on the record: the agent that works across three systems is the one that is wrong when the three disagree.
The rules change. A new discount policy, a new approval threshold, a new territory. In the routing era those were edits to a workflow that someone owned. In the acting era they are edits to the agent's instructions and boundary, and if nobody owns them the agent runs the old policy with great consistency.
The boundary moves, or should. An agent starts in draft-only mode and earns the right to send. If nobody reads the trail, the boundary never moves, and the company has bought an expensive way to draft. If somebody widens it without reading the trail, the company has bought an incident.
The connections break. Vendors change interfaces, permissions get tidied, a user whose identity an agent ran under leaves. The agent does not report that it has gone quiet. The quote that did not go out does.
Each of those is a small, ordinary piece of operational drift, and software you bought has no answer to any of them, because the purchase ended on the day the licence was issued.
A product is a point in time. The shift is a line. Buying a product for the shift means buying the point and hoping, and the hope is usually delegated to someone internal with another job.
There are two conventional ways to add the line back. One is hours: a consultancy on call, billed when something breaks, which pays the consultancy for things to keep breaking. The other is headcount: a person hired or assigned to mind the agents, who may be good and may leave, and whose contract says nothing about whether the agents' actions were right. Neither commits anyone to the condition. We laid the two out, and the third option, in managed technical operations versus managed IT: managed IT ends at the login screen, and the shift happens behind it.
The third option is the one with the right shape. A managed solution is a subscription under which one party keeps a defined condition true: the records the agents act on are complete and agree, the boundaries are current, the trail is read, the connections are up, and the agents' actions were right, measured. It is priced by usage, so it moves when the business moves. It does not end when the software is installed, because installing the software is the first week of it.
It is worth being precise, because the phrase is used loosely.
It commits to a condition, defined as numbers measured before the subscription starts: the quote turnaround, the first-reply rate, the count agreement at month end, the share of agent actions reviewed and found right. Not to effort, not to a person.
It commits one party to the whole. The records, the permissions, the connections, the instructions, the trail and the outcome are one accountability, because the failure modes cross all of them and a fault that falls between two suppliers is a fault nobody fixes.
It commits to a usage tier rather than a seat count. An agent that handles twice the records costs more to run, in tokens and in operations, and a price that does not move with volume is either overcharging the small company or starving the large one.
And it commits to the boundary moving. The point of running the shift rather than installing it is that trust is earned over time, and the subscription is the mechanism by which the agent is allowed to do more as the trail shows it should.
Here is a way to tell which shape a company bought, twelve months in. Ask the person who signed the licence three questions. How many of the agent's actions last month were reviewed, and by whom? When was the boundary last widened, and on what evidence? Which records does the agent act on that nobody has checked since launch?
A company that bought software answers none of them, not from neglect but because the purchase never created the role that would know. A company that bought the condition answers all three from the monthly report, because the report is what it is paying for. The licence fee is the same in both cases. What differs is whether anything is being kept.
A managed solution is not outsourcing the decisions. The company keeps every decision that is about the business: what the agent may do, which policy it runs, which system owns which record, what number it is measured on. The supplier keeps the condition those decisions describe. That is the same division a company already has with its accountant, who keeps the books right but does not decide what to sell.
What the buyer gives up is the comfortable fiction that the shift was bought and is done. That fiction is what the renewal invoice tests.
We run agent layers for companies of 5 to 1,000 users as a managed subscription because we have watched the other shapes fail at the renewal: the licence that ran for a month, the hours that fixed the same connection nine times, the person who left in March. Our proposals carry guaranteed estimates for the setup and a usage tier for the keeping, with one accountable party measured on the outcome. The model is a detail; the condition is the product.
Discovery is no-risk: we define the condition for the one job an agent would do in your business, take the baseline, and you pay only if you go ahead.
In a no-risk discovery we look at your CRM, finance and operations systems and who owns each part, and show what a connected system would do differently. You pay only if you proceed. Or see how we approach it.
More on the same problem:
"Something isn't working." "We're outgrowing our tools." "We're afraid to make the wrong move." No-Risk Discovery is a short, practical conversation that gets you clarity before you commit to anything big. We'll tell you if we're a fit. If we're not, we'll tell you that too.
Say who you are and ask. A person replies within one business day.
