A model that worked for years

I have been working in sales for nearly 18 years, and during that time I have seen several shifts in what clients actually expect from technology providers. For many years, the mechanism in IT was relatively straightforward: a client needed specific expertise, so they looked for a Java Developer, business analyst, DevOps engineer, or architect. The provider's role was to find the right person, agree on a rate, and ensure their availability. This model still works and, in many situations, it is simply the best solution. At Sorigo, I still work with clients in exactly this area, providing IT outsourcing and flexible team augmentation.

When specialist availability is only the beginning of the conversation

At the same time, I increasingly see that having the right specialist available is no longer the end of the conversation. A client may start by saying they need six people for a project, but after a longer discussion it turns out that the real problem is not the lack of six people. The problem may be that deployments take too long, the team cannot carry out a migration, the company has accumulated technical debt, or it lacks the expertise needed to launch a specific product. And that is when the conversation about CVs and rates is only just beginning.

That is why the first conversation with a client looks different today than it did a few years ago. Before asking about technology, rates, and the expected start date, I try to understand four things. Why does this project need to start now? How much is the current situation costing the client—in time, money, or risk? What will success look like? And who on the client's side makes the decisions that determine the outcome? That last question can be the most uncomfortable, but it is crucial. A provider can only be accountable for an outcome to the extent that they can influence the factors that lead to it. If the result depends on decisions, access, or data on the client's side, responsibility needs to be divided fairly and defined in the contract rather than negotiated only when a dispute arises.

What the data tells us

What I see in conversations with clients is also reflected in the data. According to Forrester, which surveyed more than two thousand decision-makers responsible for purchasing technology services, more than half already use outcome-based pricing models, while 46 percent use fixed-price contracts. Hybrid models are also becoming more common, with different pricing mechanisms applied at different stages of the same project.

A similar direction can be seen at McKinsey. The company reports that more than 30 percent of its fees are now directly linked to the outcomes achieved by its clients. Strategic consulting and IT services are, of course, not the same market, but the underlying mechanism is similar: an increasing share of a provider's value is being priced based on the outcome rather than solely on the time spent.

Three situations, three engagement models

In practice, I see three typical situations where different engagement models make sense. First, the client has its own architecture, team, and management processes, but lacks a specific skill set or additional capacity. In that case, providing a specialist solves the problem, and time-based billing is fair because the client controls the work. Second, the client has a clearly defined goal but lacks the people or time to manage the project themselves. Here, a fixed-price or milestone-based model is often a better fit, with clearly defined acceptance criteria. Third, there is an area that needs to be managed continuously—for example, platform maintenance, monitoring, or product development at an agreed pace. In such cases, a managed service with a subscription fee and measurable service-level indicators is a natural solution.

The most interesting cases, however, happen between these models. Increasingly, an engagement starts with a short, paid discovery phase in which the team gets to know the system and assesses the risks. Only afterwards is the model for the next stage defined: a fixed scope, a capped budget, or classic team augmentation. This approach is fairer to both sides because a fixed price agreed before the project has been properly assessed is, to a large extent, guesswork.

The trap of hourly billing

This has major implications for how technology companies will build their service offerings. In a straightforward model, a project can be calculated as six people multiplied by 160 hours per month multiplied by an agreed rate. It is transparent, the client knows exactly what they are paying for, and the provider knows exactly what they are selling.

But if a smaller, highly effective team supported by the right tools can achieve an outcome that previously required a much larger number of people, traditional time-based billing starts to reward lower efficiency rather than higher efficiency.

AI is accelerating the shift

AI is accelerating this process even further. At the beginning of 2026, TCS reported that its annualized AI services revenue had reached $1.8 billion, growing by more than 17 percent in a single quarter. A few months later, it had reached $2.6 billion. This does not mean that the traditional services model is suddenly disappearing. It does, however, show the pace at which major technology providers are building new revenue streams and new ways of delivering services around AI.

There is another side to this that is discussed less often. When a provider uses AI to develop software, clients start asking new questions: Who is responsible for the quality of the code? How is the data protected? Who owns the rights to the resulting solution? And how can the client verify that faster delivery is not coming at the expense of security? A provider that already has clear answers to these questions has a very different conversation with the client than one that only has a list of available skills.

More difficult sales and a different provider organization

From a sales perspective, this is much more difficult. It is far easier to tell a client that you can provide a senior developer starting next month and give them a rate than it is to take responsibility for solving a specific technology problem.

In the latter case, sales needs to understand the project's delivery model, technology, risks, and economics much more deeply. It is also necessary to understand where the client's responsibility ends and the provider's begins. A poorly priced fixed-price project can look like a great sale on the day the contract is signed and turn into a terrible business decision six months later.

This also changes how the provider needs to be organized. In an hourly model, a salesperson can often operate almost independently: check availability, agree on a rate, and pass the requirement to recruitment. In an outcome-based model, pricing becomes a joint decision involving sales, delivery, architecture, and finance. The way success is measured changes as well. In team augmentation, specialist utilization and margin per hour are key metrics. In projects and managed services, accurate estimation, overall project margin, and the number of times the provider has had to return to the client with a price adjustment during delivery become equally important. A company that fails to adapt will continue selling projects the way it sells hours—and will pay the price during delivery.

How clients see it

Clients are not moving in the same direction at the same pace either. Procurement departments are used to comparing hourly rates because they are easy to put side by side in a spreadsheet. Outcome-based offers are harder to compare and even harder to justify internally. It can be difficult to explain why a more expensive line item in a spreadsheet may actually result in a lower total project cost. This can still be seen, for example, in tenders for IT specialists, where evaluation criteria are often still primarily based on price and the time required to replace a consultant. The transition is therefore likely to be gradual. It will begin where the purchasing decision is made by someone responsible for the business outcome of a project, rather than solely for the budget allocated to resources.

Body leasing is not going away

For that reason, I do not expect body leasing or team augmentation to disappear. I see firsthand how much value flexible team augmentation can provide to organizations that need to quickly fill capability gaps without building every specialization in-house. At Sorigo, this is exactly how we work. Alongside traditional body leasing, where the client identifies the expertise they need and we find the right specialist, we also deliver projects in areas such as Data Engineering and Cloud. In these engagements, the starting point is not the number of people required, but a specific problem to solve and an outcome the client wants to achieve. Increasingly, these two approaches are also being combined within a single engagement with the same client.

Where a good conversation starts

After many years in sales, I am increasingly convinced of one thing: the best conversation with a client does not start with the question, "Who do you need?" It starts with understanding what actually needs to change in the client's organization when the project is completed. Only then can you honestly determine whether the best solution is one specialist, an entire team, or a comprehensive managed service.

People are still part of the answer. Increasingly, however, they are no longer the whole answer.