What is digital labor?
Digital labor is work performed by software that is purchased as capacity rather than as a licence. The distinction from ordinary software is the unit: you are not buying a tool that a person uses, you are buying an amount of work that gets done.
That is why pricing follows usage. On ftes.ai a plan buys a block of work metered in tokens, drawn from one organization wallet by every Digital FTE hired. The unit is the work, which makes the purchase comparable to capacity rather than to a subscription.
Why does converting fixed cost to variable cost matter?
Converting labour from a fixed to a variable cost matters because it changes the risk of being wrong. A full-time hire is a large, slow-to-reverse commitment made on a forecast; if the forecast is wrong, the cost persists while the need does not.
Digital labor inverts that. A quiet month costs less than a busy one, a workflow that does not pan out simply stops, and a pilot can be sized to a single function and a single property. The value is not only that the unit cost may be lower; it is that the decision is reversible, which lets a business try things it would not risk a headcount on.
What does decoupling output from headcount actually mean?
Decoupling output from headcount means a function's throughput is no longer bounded by how many people the business can recruit, ramp, and retain. For most operational functions that bound has been the real constraint, not ambition or budget.
The honest version of this claim is narrower than the headlines suggest. Output decouples from headcount only for the parts of a function that are continuous and evidence-driven. The judgement, the relationships, and the accountability stay with people, and those parts still scale with hiring.
Where does the constraint move to?
When digital labor removes the execution constraint, the binding constraint moves to review capacity and process clarity. Those are the two things that determine how much digital labor a business can actually absorb.
Review capacity is how much approving and deciding the responsible humans can do, which is why the autonomy ladder is an economic mechanism and not just a safety one: promoting a class of action releases review capacity. Process clarity is whether the business has actually agreed how the work should be done, because digital labor inherits the ambiguity of its remit rather than resolving it.
How should a finance team model digital labor?
A finance team should model digital labor as a variable operating cost tied to a volume driver, and compare it against fully loaded cost rather than salary. The fully loaded figure includes benefits, payroll taxes, software seats, management overhead, recruiting, and the ramp period before a new hire is productive.
The second modelling decision is where the savings actually land. In most deployments the near-term effect is not headcount reduction but capacity increase at flat headcount: the same team ships more because the coordination work moved. Model that as revenue or coverage impact rather than as cost reduction, or the business case will measure the wrong thing.
- Model as variable cost tied to a volume driver, not as a fixed licence
- Compare against fully loaded cost, never against base salary
- Expect capacity gain at flat headcount before any headcount effect
- Include review time as a real cost of the operating model
Does digital labor replace jobs?
Digital labor changes the composition of a function's work before it changes the number of people in it. The parts that move first are continuous, evidence-driven, and coordination-heavy; the parts that remain are judgement, relationships, and accountability, which do not compress.
The pattern most businesses actually experience is a shift in what the existing team spends time on rather than a reduction in the team. Whether that stays true at a larger scale is a genuinely open question, and anyone claiming certainty in either direction is guessing. What is certain is that accountability for an action stays with the person who approved it, which keeps a human in every consequential decision.
What is a labelled example of the fixed-to-variable shift?
As a labelled example with your own numbers to fill in: a support function staffed with people has a fixed monthly cost that does not change when ticket volume halves in a quiet month or doubles in a launch week. The same first-line resolution owned by a Customer Support Digital FTE has a metered cost, tokens consumed for the tickets actually resolved, drawn from the organization's wallet and bounded by a per-FTE budget. In the quiet month the cost falls; in the launch week it rises, up to the budget and no further.
The comparison is honest only with a recorded baseline. Record the fixed cost and the volume it handled before the pilot, run two full cycles, and compare cost per resolved ticket from usage per role in the workspace. The shift from fixed to variable is not automatically a saving; it is a change in how cost behaves, and its value depends on how much the volume varies and how much of the work was repetitive. The record, not the model, says whether it paid.