After time-and-materials: four models for selling capacity, a service or a result

AI doesn't spell the end of staff augmentation. It does, though, create a very concrete economic problem for IT services firms: when more work can be produced, checked or automated with less human time, the number of days consumed explains the value created less and less well.

The shift is already noticeable. In France, 72% of the IT services and engineering firms surveyed by Numeum and KPMG said in 2025 they use generative AI in their delivery. In the first half of 2026, 49% of the firms surveyed by Numeum-Xerfi cited pricing pressure among their top headwinds, and 58% said they're repositioning through automation and AI.

But "moving past the day rate" doesn't lead to a single model. Fixed price, capacity subscriptions, managed services and monetising assets don't allocate risk, margin, or accountability the same way.

What comes after staff augmentation isn't outcome-based pricing. It's the shift from one dominant sales unit — the day — to a portfolio of contract models chosen around three questions: what can genuinely be controlled, what can be measured, and what can be reused?

In brief

• •Staff augmentation isn't disappearing. It stays rational when the scope is uncertain, human expertise is rare, or the client wants to keep control of delivery.
• •What AI mainly weakens is the link between effort and value. If the same team produces more, selling only days puts either the provider's revenue or the client's trust at risk.
• •Four models deserve to be told apart. Agentic fixed price, capacity-as-a-service, outcome-oriented managed service, and asset-based service each answer a different situation.
• •Hybrid models will probably prove more robust than radical switches. A fixed portion often pays for capacity and risk; a variable portion pays for usage, service level, or outcome.

What's genuinely changing: staff augmentation is being challenged, not doomed

The sector signal now exists explicitly. At its first ESN & ICT Forum, in June 2026, Numeum summed up the shift like this: day-rate staff augmentation is increasingly challenged by engagements built on capacity, outcome, or shared gain. This source needs proper qualifying, though: it's a summary of discussions among more than 60 sector leaders, not a statistical survey proving the entire market has shifted.

This finding echoes a broader trend in knowledge services: a gradual shift from person-time toward outcome-based, Consulting-as-a-Service and asset-based models — with a standing warning against the simplistic reading that just demands lower day rates because AI speeds up certain tasks.

Transposing this to IT services firms, though, needs care. An IT services firm doesn't just sell analysis or an intellectual deliverable. It can take accountability for a production system, maintain an application for years, guarantee availability, absorb incidents, or integrate heterogeneous systems. The most measured conclusion, then, is that the day rate can survive as a billing unit, but it's increasingly insufficient to tell the whole value story for certain engagements.

The problem isn't the day rate itself. It's the day rate used to sell work whose value is increasingly decoupled from the number of days needed to produce it.

The data shows a transformation in delivery, not yet a revolution in revenue

It would be tempting to chain three arguments together: AI raises productivity; so IT services firms will need fewer people; so clients will soon stop buying days. The available data doesn't let us move that fast.

The 2025 Numeum-KPMG study shows AI is already widely spread through delivery: 72% of the companies surveyed said they use it, out of a sample of nearly 200 IT services, engineering and technology consulting firms. This documents adoption, not a uniform productivity level, nor an equivalent contractual shift across every respondent.

Deloitte's global outsourcing survey offers an even more useful counterpoint. Among more than 500 executives, 83% said they use AI in outsourced services. Yet only 25% observed a reduction in vendor costs or an improvement in service quality. Deloitte, at the same time, notes outcome-oriented models are on the rise.

Introducing AI into delivery doesn't automatically mean a better service, a better margin, or a new contract.

ISG, for its part, observes that GenAI agents are gradually entering European application development and maintenance — development, testing, application management — which strengthens the technical case for industrialising certain service engagements. Its 2025 study covers 33 European ADM service providers.

An organisational signal rounds out this picture: in a panel of thirty companies observed, a "human on exceptions" model shows up, where automation absorbs the standard cases and humans handle the uncertain situations. Roundtable is a telling case: according to an account gathered, a process covering 1,000 SPVs can be automatically sorted so that only fifteen to twenty problem cases reach a human. This case shows operational volume can decouple from human workload. It doesn't prove a client will agree to pay for that capacity under a new model, or that the sorting quality would transfer to just any process.

This is exactly where the business-model question begins.

Four models beyond staff augmentation

These four models aren't a recognised market taxonomy. They form a lens built from the models observed in knowledge services and IT-services sector research.

Model 1 — The agentic fixed price: selling a bounded transformation rather than the days it takes

The fixed price obviously didn't wait for AI. What's changing is the provider's ability to sharply cut the effort spent on certain steps: analysing a codebase, generating tests, documentation, first-pass fixes, standardised migrations or conversions.

In a fixed-price contract, the provider can, in theory, keep part of the productivity gain: if the price is tied to the accepted scope and not the number of people deployed, producing more efficiently improves its margin.

This is what makes the agentic fixed price interesting. The term here refers to a fixed-price engagement where a significant share of delivery is entrusted to agents, with acceptance criteria and human oversight designed into the contract from the start.

This model becomes credible when three things can be stabilised: the scope, the acceptance criteria, and the reversibility terms. A well-specified migration, boosting test coverage, refactoring an identified component, or producing structured documentation all fit it better than a transformation whose need the client is still discovering.

The decisive point, then, isn't "how much code can AI write?". It's: "can we objectively say whether the delivered work is correct?"

Otherwise, AI raises a classic fixed-price risk: producing something quickly that will need extensive rework later.

The provider then has to fold testing, evals, regression testing, security and human review into its total cost. The real margin isn't simply the fixed price minus salaries. It also has to include the models used, compute, licences, quality controls, and maintaining the agentic tools.

Relevant hybrid model: a fixed price for the build + a staff-augmentation allowance for the parts that can't be specified. Staff augmentation, here, isn't the old model kept by default; it explicitly funds the uncertainty.

Model 2 — Capacity-as-a-service: stop selling five people, sell available capacity

The second model answers the fixed price's mirror-image weakness: many digital needs can't be pinned down early enough.

A product team, a data domain, or an internal platform may know they'll need durable development and maintenance capacity without being able to specify today the full feature set for the next six months.

Staff augmentation has historically answered this uncertainty very well: the client buys people and decides afterward how to use them.

Capacity-as-a-service tries to keep this flexibility while changing what's sold. The client no longer buys five named developers for a quarter. Instead, it buys, for example, delivery capacity in a given domain, tied to response times, service classes, governance and quality criteria.

The contract focuses more on what the delivery system can absorb than on each individual's day-to-day presence.

This logic is close to Consulting-as-a-Service, but transposing it to IT services firms needs to be more operational: a digital service has to specify what falls within the capacity, what happens when demand exceeds it, how emergencies are handled, how quality is measured, and who's accountable for production.

The economic upside is twofold. The client gets a more predictable budget envelope. The IT services firm can freely choose its mix of seniors, juniors, specialists and agents as long as it meets its commitments.

But this model has an obvious anti-pattern: staff augmentation dressed up as a subscription.

If the sales pitch stays "four developers and a Tech Lead", just billed monthly under the label "capacity", nothing has genuinely changed. Capacity needs to be described by the service delivered, its throughput, its constraints and its quality levels — not just FTEs hidden behind a new name.

This model fits especially well when product uncertainty stays high and the final outcome still depends heavily on the client's own decisions. It avoids asking the provider to guarantee a result it doesn't control enough.

Relevant hybrid model: a capacity subscription + billing for exceptional overages + a capped bonus on certain delivery indicators.

Model 3 — The outcome-oriented managed service: selling a performance level you can genuinely steer

The managed service changes how accountability is allocated more fundamentally.

The provider no longer just supplies capacity to produce. It takes ownership of a process or a system over time: application maintenance, cloud, service desk, security, running a platform, application quality, or business operations.

AI strengthens the appeal of this logic because it lets you absorb part of the standard volume without headcount growing proportionally: automatic sorting, first-pass diagnostics, incident classification, fix suggestions, test generation, or predictive monitoring.

But "outcome-oriented" doesn't necessarily mean "paid solely on the outcome". That's often even a bad idea.

In a real IT system, availability, MTTR, release frequency, or running cost also depend on the client's legacy systems, data quality, other vendors, business trade-offs, or scope changes.

Transferring all of that risk to the IT services firm leads either to very high prices, or to endless disputes over attributing the results.

The most defensible model, then, is often hybrid: a fixed operations base + SLA/SLO commitments + a capped variable share on a few performance metrics the provider can genuinely influence.

The key question here is control. You can reasonably hold a provider to an incident-response time if it owns operations. It's far harder to hold it to a product's revenue growth if pricing, marketing, product and distribution stay under the client's control.

The further the outcome sits from the scope the IT services firm controls, the more cautious the contract needs to become again.

Model 4 — Asset-based service: selling multiple times what used to be rebuilt on every engagement

The fourth model is the one that most directly changes an IT services firm's economics.

A connector, a sector-specific library, a migration engine, an eval system, a diagnostic agent, a compliance accelerator, or an operational cockpit can be built during a first engagement and then reused.

Instead of starting delivery entirely from scratch, the IT services firm capitalises on and monetises intellectual property — an asset-based-consulting logic: reusable assets can be monetised through licensing, subscription, or usage.

For an IT services firm, the business model can combine four layers: usage rights to the asset, initial integration, operations and maintenance, and possibly variable usage.

The Palantir case is instructive because it has long blurred the line between software and services. The company's official documentation states its platforms are built using a Forward Deployed Engineering methodology, where engineers work in direct contact with clients' operational environments.

This case shows the potential power of combining a proprietary software asset with human deployment capacity. It doesn't prove every IT services firm needs to become a software vendor, or that this combination mechanically produces better margins.

The difficulty is precisely here: moving from "we built an accelerator" to "we own a maintainable, sellable product" is an organisational change.

A monetisable asset needs an owner, a roadmap, versions, tests, a security policy, a maintenance cost, licensing terms, and a support model. Otherwise, the IP portfolio quickly turns into a graveyard of unmaintained POCs, prompts and scripts.

The other difficulty is contractual. In IT projects, clients frequently ask for significant rights over the code produced. So the provider's pre-existing assets, what's co-built, and what specifically belongs to the client need to be precisely distinguished.

Relevant hybrid model: a licence or subscription for the asset + a fixed-price integration + a managed service for ongoing operational upkeep.

The real choice isn't between four models — it's about three questions

It would be tempting to roll out a new "outcome-based" offering just because it looks more modern than a staff-augmentation one. That would repeat, with the business model, a mistake already common with AI: starting from the solution before characterising the problem.

The higher the uncertainty, the more rational it stays to sell time or capacity. The more controllable and measurable the result, the more possible it becomes to sell a service or a performance level. The more repeatable the solution, the more possible it becomes to sell an asset.

Why hybrid models should dominate the transition

The four models aren't mutually exclusive. A single account can combine several of them.

A discovery phase can stay on the day rate because the problem itself isn't yet stable. A well-specified modernisation then moves to a fixed price. The tool built during that phase becomes a licensed asset. And running the new platform gets handed off to a managed service with SLAs.

This scenario isn't a temporary compromise. It can be a durable contractual architecture.

This hybridisation also protects both parties against a poor allocation of risk.

The client has no interest in indefinitely paying more just because the provider uses more people than it needs to. But the provider, equally, can't guarantee a result when half its drivers stay in the client's hands.

The contract, then, becomes less a matter of "new AI pricing" than an explicit architecture of accountability.

For procurement, the issue isn't asking "how many days does AI save?"

Buyer pressure on the day rate is understandable. If part of the work is automated, why keep paying exactly as before?

But this question can lead to a poor optimisation. A cheaper engagement can produce more rework, shift review costs onto the client, or mask insufficiently controlled automation. Conversely, a provider can't use AI as an abstract justification for keeping the entire productivity gain while changing none of its commitments.

Procurement, then, needs to shift the discussion toward five things: the baseline, the quality criteria, the human-agent split, accountability, and intellectual property — moving from a negotiation essentially centred on the price of time toward a reading of the proof, the impact, the governance, and the assets left with the client.

For the provider, this transparency can feel risky. It's still a condition for capturing part of the value AI creates.

It's hard to defend a new pricing model while keeping the old model of proof.

Changing the revenue model forces the IT services firm itself to change

A new pricing scheme doesn't hold up long if the organisation is still run like a staffing agency.

A salesperson paid almost exclusively on the number of consultants staffed will naturally want to defend staff augmentation. A manager evaluated on utilisation rate will hesitate to invest time in a reusable asset. A BU whose P&L doesn't break out model, compute and maintenance costs won't know the real margin of an agentic offering.

You don't become asset-based by having a library of accelerators. You become asset-based when you agree to fund, manage and sell some of those accelerators like products.

Likewise, you don't become outcome-based because a proposal contains a bonus. You become outcome-based when operations are measured well enough to isolate what genuinely counts as the provider's own performance.

What could invalidate the "after staff augmentation" thesis

There are at least four reasons not to extrapolate too fast.

First, AI's productivity gains remain highly variable. High adoption doesn't guarantee a better total cost, as shown by the gap between the 83% of AI users in outsourcing surveyed by Deloitte and the 25% who report lower vendor costs or better quality.

Second, staff augmentation has a deep economic advantage: it's simple to understand, and it lets the client keep the scope risk. The more uncertain the environment, the less free it is to transfer that risk to a provider.

Third, clients don't always want more outsourcing. Deloitte reports 70% of the organisations surveyed had selectively brought certain activities back in-house over the previous five years, even as a large majority planned, at the same time, to maintain or increase their outsourcing spend.

Finally, asset-based models can recreate a problem procurement already knows well: lock-in. The more a provider sells a proprietary platform, the more it needs to be able to explain reversibility, data portability, and the boundary between its asset and the client's own IP.

These limitations don't overturn the thesis. They sharpen it.

There probably won't be a single model "after staff augmentation". There will be a market where staff augmentation stops being the automatic answer to problems that can now be contracted for better in other ways.

Self-diagnostic: can your offering genuinely move past staff augmentation?

• •We know how to define a baseline before the engagement starts.
• •We can measure quality some other way than sticking to staffing and schedule.
• •We can tell apart the results we control from the ones that mainly depend on the client.
• •Our acceptance criteria let us objectively verify output partly produced by agents.
• •Our "capacity" offering is expressed in service and performance-level terms, not just relabelled FTEs.
• •For a managed service, we know the exception rate, the rework, and the real cost of human oversight.
• •Model, compute, licence and quality-control costs are built into our margin calculation.
• •We know which components of our projects are genuinely reusable intellectual property.
• •Every asset we want to commercialise has an owner, a maintenance policy, and clear usage rights.
• •Our salespeople can negotiate a combination of fixed, capacity, usage and performance, not just a day rate.
• •Our contracts make human accountability, reversibility terms, and the boundary between our assets and the client's explicit.
• •We can explain to the client why the new price better matches the value, without simply invoking AI.

If several answers stay no, the problem probably isn't the pricing choice yet. It's the maturity of delivery, of measurement, or of intellectual property.

The conviction

AI makes a significant transformation of IT services firms' business model possible, but the starting point isn't the technology.

The real change is that human effort becomes a less reliable measure for certain engagements.

When the work can be specified, it becomes possible to sell a scope and a proof. When the need stays fluid, it's possible to sell capacity rather than individuals. When the provider genuinely masters a process, it can sell a service level and take a reasonable share of the performance risk. When the solution recurs, it can turn its know-how into an asset and create revenue that no longer directly depends on the number of days produced.

Staff augmentation keeps its place wherever uncertainty, rare expertise, or client-side governance make it rational.

The strategic question for an IT services firm, then, isn't "how do we move past staff augmentation?". It's: "for every offering, what should our clients genuinely be buying from us: time, capacity, a service, an outcome, or an asset?"