The Three Roles in Big Software Deals
When a large enterprise needs a serious software system, it rarely buys a product and runs it as-is. Complex packages from vendors like SAP, Oracle, or Salesforce require significant installation, configuration, and customization work. Most customers don't want to build that expertise internally, so they bring in skilled staff from a services firm such as Accenture, Wipro, or Thoughtworks. This three-way relationship—customer, product vendor, and service provider—is so common that the product and services companies often sign partnership deals to cooperate on specific installations or entire market segments.
These arrangements are widespread, but poorly understood, even by people who work mostly in custom software development. That matters more now because the shift to cloud computing has brought similar partnership structures into the custom software world, where they are having a visible impact on companies that focus on delivery.
Partnerships can form at different scales. The simplest case is a partnership created for a single customer engagement, either because the customer tells the product vendor to work with its preferred service provider, or because the two companies spot the opportunity together, often in competition with another product-service pairing. More involved arrangements are long-term deals covering multiple customers, possibly restricted to a particular business sector or geography.
A key variable is the relative size of the companies. A small service provider has a fundamentally different relationship with SAP than Wipro does. The typical assumptions below apply when both partners are large.
Partnerships Require Dedicated Organizations
When both companies are large, partnership arrangements are usually non-exclusive. A firm like Accenture does ERP work with both SAP and Oracle across many customers worldwide. The scale is such that a service provider often creates entire organization structures for a single partner—in the mid-2000s, IBM Global Services had around 20,000 staff dedicated to SAP work.
A service provider might have a banking division focusing on that sector and a separate Oracle division focusing on Oracle's business software platforms. If a bank wants to reform its HR systems, it talks to a contact in the banking division. People in that part of the services company try to stay relatively vendor-neutral. If the customer decides to implement PeopleSoft—an Oracle subsidiary—the banking contact introduces staff from the company's Oracle division as part of the work.
Large product vendors, in turn, maintain dedicated partner organizations that provide education and product news, help with sales pursuits, and coordinate delivery work. In both cases, a partnership is not just a signed contract but an ongoing relationship requiring constant maintenance.
Why Vendors Don't Build Their Own Services Arms
From the product vendor's perspective, the service provider is essentially a delivery organization. Vendors generally avoid building their own delivery capacity for several reasons. Services work carries much lower margins than selling product, so vendors prefer to invest in the product and in sales and marketing. Installation projects also carry significant risk, and an arms-length relationship with delivery means the service provider bears responsibility when things go wrong.
Revenue recognition is another financial driver. Software sold today counts as revenue immediately, but services revenue is only recognized when the work is done—even if the contract is signed months earlier. If a deal bundles services with a product sale, it becomes hard to avoid deferring recognition of the software revenue as well. Keeping a bright line between the product sale and the delivery work—which a separate services provider helps maintain—is a considerable incentive.
The difficulty compounds when a delivery organization must integrate products from multiple vendors. The product vendor then faces not only risks from its own product, but also risks from other companies' products, sometimes in competitive relationships.
Many product vendors have tried building a services arm to get a deeper customer relationship, and most customers would prefer working directly with the vendor for a more direct line when problems arise. But these efforts usually don't last, as the vendor runs into the problems described above and pulls the plug. IBM is a notable exception.
Service providers, accustomed to billing for professional time and managing complex projects, see partnerships as largely defensive. When competing for a product installation engagement, customers look for expertise and connection with the product. A partnership arrangement provides that assurance, and lacking it raises questions.
Certifications as a Measure of Commitment
The number of staff a service provider dedicates to a product is an important element of the relationship. Most product vendors run certified training programs. The quality of these programs is often poor, and accumulating certifications doesn't reliably indicate competence. Even a well-run course tends to focus on the quirks of an individual product rather than broader technical principles, which are usually more important—and such training is unlikely to discuss approaches that don't involve the vendor's product.
Despite these flaws, partnership deals frequently include certification targets specifying how many service provider staff reach various levels. Certification training is revenue for the product vendor, signals the service provider's commitment to the relationship, and at least ensures a basic familiarity with product features.
Commissions and Softer Incentives
Some partnership deals involve commissions, in either direction. A service provider that sells work—an initial project or follow-on modules—may earn a sales commission on the software sale. Similarly, a product vendor that introduces a services company may earn a commission on billed hours. Some service providers deliberately forgo commissions to preserve their client-focused advisory role, which is easier to sustain if they have significant work with several competing vendors.
Financial incentives exist even without explicit commissions. Software vendors typically rank service providers by revenues the provider has influenced. That ranking affects referrals, access to product plans, and the quality of technical support. Similarly, leaders of a service provider's product-focused division are evaluated on the billable work they sell and the margins they sell it for.
Partnerships also involve joint sales and marketing campaigns aimed at generating more business for both companies. These efforts usually don't produce much. Nobody believes the go-to-market plan until the first deal closes, and even then there is often little trust between organizations. When such a deal works, it is usually due to an unusual circumstance—often an especially strong working relationship between specific individuals. Both sides must remember they are dealing with only one part of the partner organization. Other parts of the service provider won't jeopardize client relationships just to sell product-based delivery work, and other parts of the product company don't want to damage relationships with other service providers. As with so much in business, how smoothly the partnership works is primarily a function of the personal relationships among the leaders involved.
When Partners Have Conflicting Loyalties
Service providers are often hired both to implement systems and to advise on which products best support a business function. That advisory role collides with product-vendor partnerships whenever a provider must recommend against a partner’s product. The conflict is sharpest when sales commissions are at stake, but even without them, vendors rank partners by the revenue they influence, giving providers a financial reason to steer customers toward partnered products.
Practitioners at large service firms generally dismissed this as a non-issue, noting that advisory work usually sits in a different division from the one managing partnerships. They also argued that maintaining partnerships with several competing vendors dilutes any bias.
Asymmetrical Deals Bring Exclusivity
When partners are mismatched in size, exclusivity clauses appear. A small product vendor matters little enough to a large service provider that it can be asked to work exclusively with that provider, at least within a market segment or geography. The service provider’s motivation shifts from market necessity to competitive edge, using exclusive access to a product as a differentiator, often bundling several small products and marketing integration expertise.
That size imbalance also gives the service provider leverage over product roadmaps and pulls priority for technical support. For the smaller vendor, the rationale is mostly sales and marketing reach, since building an enterprise sales organization is costly. Handing customer access to a services firm is a trade-off most accept in exchange for credibility that the vendor will survive.
The same dynamic runs in reverse: large vendors partner with small service providers to gain deeper alignment. That can mean exclusivity agreements and even clauses that make criticizing the product a firing offense. The result is more energetic selling, a larger cut of consulting fees for referred customers, and little room for objective advice.
The Cloud Reshapes Partner Economics
Cloud platforms from Amazon, Google, and Microsoft have made partnerships nearly unavoidable for custom software development. In the past, developers could avoid vendor entanglements by sticking with open-source languages and frameworks with no partnership required. Today, custom software is built on cloud stacks, and effectively running it requires deep knowledge of vendor services and infrastructure management. A service provider can no longer stay neutral.
The cloud’s pay-for-usage model also adds a perverse incentive dimension. Unlike software licenses, where revenue is settled at purchase, usage billing means every design decision affects the vendor’s revenue stream. Since service providers are rated by the revenue they generate, a designer integrating sensor data has an implicit push to route all alerts to the cloud rather than minimize processing costs.
What Customers Should Demand
Partnerships are not a hidden wrinkle but a known part of the game that customers must factor into their evaluations. Sources insisted CTOs understand the dynamics and therefore had nothing to worry about — a claim worth skepticism.
Transparency is the essential first defense. Customers should require partners to disclose partnership terms, including any sales commissions, so they can weigh whether advice is genuinely in their interest. Customers should also be wary of recommendations that favor a partner over a non-partner competitor.
On joint projects, customers need clarity about each partner’s responsibilities and how disputes will be resolved. The absence of such defined lanes is a red flag, as ambiguity early on worsens under pressure later.
Certification pressure from vendors can also lead to staff with surface-level familiarity rather than deep technical understanding. Customers should probe for people who grasp the underlying principles and can, where appropriate, build alternatives to a product rather than just operate it.
The partnership model itself makes outcome-focused work harder. Service providers bill by the hour, not by the customer’s improvement, and it is difficult to construct a financial measure tied to outcomes. That output-centered friction already complicates direct vendor-customer relationships; in a partnership it is amplified, as both partners focus on their own deal rather than the customer’s results.
The influence of cloud vendors means service firms cannot avoid deciding which partnerships to join and how to manage them. Customers of digital businesses should push for openness about those deals, because the health of their own operations depends on how their critical suppliers cooperate.
