PRM Was Built Vertically. Cross-Company Work Needs a Horizontal Layer
Traditional PRM assumes one company manages its partner ecosystem. Horizontal cooperation needs a different operating layer for temporary work between independent firms.
Most business software assumes that somebody sits at the center of the relationship.
CRM is built around a company and its customers. Partner Relationship Management usually assumes a company managing dealers, resellers, affiliates, suppliers, or another defined partner ecosystem. Procurement software assumes a buyer interacting with suppliers.
But there is another type of business relationship that fits these structures poorly.
Several independent companies may discover that they face the same operational problem, need similar work, or could benefit from combining selected resources. None of them owns the others. None needs to become the permanent center of an ecosystem. They may want to cooperate only around one narrowly defined task and then separate again.
This is the problem space we call horizontal cooperation infrastructure.
A useful shorthand is horizontal PRM: partner relationship management designed not around one company controlling a partner network, but around independent peers forming a bounded working relationship.
That sounds like a subtle distinction. Architecturally, it changes almost everything.
Horizontal cooperation is not new
Businesses have cooperated horizontally for decades.
Research on cooperative purchasing describes multiple organizational forms in which independent organizations combine purchasing activities, information, volumes, or resources. Research on co-commissioning shows organizations jointly commissioning services from a provider even when the participating organizations remain institutionally separate.
Industry practice provides similar examples. NADA 20 Groups deliberately bring noncompeting automotive dealers together to compare performance, exchange operating knowledge, and solve business problems with peers.
So the behavior is not new.
What is still fragmented is the operating infrastructure around temporary cooperation between independent firms.
Much of this activity still happens through associations, spreadsheets, email threads, messaging groups, personal relationships, consultants, procurement departments, and one-off contracts.
The cooperation exists. The software layer is often missing.
Our first CLAD Research paper examined the economics of horizontal production cooperation in the age of AI. Read CLAD Research Series #1, Optimizing Between Firms: Horizontal Cooperation in the Age of AI, on SSRN.
This article asks a different question:
What would software built specifically for horizontal cooperation need to manage?
Why traditional PRM only partly fits
Traditional PRM solves an important problem: helping an organization manage relationships with a known or semi-known partner ecosystem.
That architecture usually has a recognizable center.
A manufacturer manages dealers.
A software vendor manages resellers.
A platform manages complementors.
A brand manages affiliates.
Horizontal cooperation can look very different.
Imagine four independent businesses that want to commission one shared piece of professional work while keeping their brands, customer data, prices, commercial decisions, and individual adaptations separate.
Who owns the relationship?
Potentially, nobody.
The important object is not a permanent relationship between a principal and its partners.
It is a temporary shared scope between independent organizations.
That scope may exist for six months, six weeks, or one project. Participants can join because of one compatible need and have no reason to remain partners afterward.
A horizontal system therefore needs to manage not only partner relationships but also formation, commitment, execution, change, and dissolution of temporary multi-company work.
Traditional PRM vs. Horizontal Cooperation
Traditional PRM and horizontal cooperation may both involve relationships between companies, but they organize those relationships around different operating objects. The distinction becomes clearer when the two models are compared directly.
| Dimension | Traditional PRM | Horizontal cooperation layer |
|---|---|---|
| Relationship structure | One focal company manages a partner ecosystem | Independent companies cooperate as peers around a bounded shared scope |
| Primary object | Partner account or relationship | Shared scope plus participant-specific scope |
| Control model | A principal organization usually defines the program | Governance is agreed for the cooperation; no permanent principal is required |
| Compatibility | Often linked to partner status or program membership | Scope-specific and potentially temporary |
| Lifecycle | Usually designed around an ongoing partner relationship | Formation → commitment → execution → closure |
| What is shared | Access, opportunities, resources, and program information | Only the explicitly agreed common work, resources, or assets |
| What remains separate | Defined by the focal organization’s partner model | Brand, commercial decisions, private data, individual work, and exceptions |
| Success | A stronger or more productive partner relationship | Completing the shared task efficiently while preserving participant independence |
| End state | Relationship retention is usually desirable | Clean separation can be a successful outcome |
The difference is therefore not simply who the partners are, but what the system is designed to manage.
The missing object is the shared scope
Consider what a conventional relationship record tells you.
It can tell you who the partner is, what organization they belong to, their status, permissions, agreements, contacts, opportunities, and history.
A temporary horizontal coalition needs another object:
What exactly are these firms doing together?
That object must distinguish at least two layers.
The first is the shared scope: the work, asset, service, research, infrastructure, or production component that participants have agreed to fund or execute together.
The second is the individual scope: everything that remains controlled separately by each participant.
This separation matters.
Without it, collaboration easily turns into a committee in which every participant starts influencing every other participant's work.
Horizontal cooperation works better when the common boundary is explicit and narrow.
The objective is not to make participating companies more alike.
It is to let them cooperate where their interests overlap while remaining independent everywhere else.
What horizontal cooperation infrastructure has to manage
A horizontal system needs capabilities that ordinary relationship management does not always treat as first-class objects.
Discovery
Which organizations might have compatible needs?
This does not necessarily mean building an open marketplace. Existing peer networks, associations, professional communities, brand networks, and known noncompeting firms can already provide a starting population.
Compatibility
Two firms can be suitable partners for one scope and unsuitable partners for another.
Compatibility therefore cannot be a permanent label attached to an organization.
It is scope-specific.
The same two firms might safely share generic training infrastructure while being completely unsuitable partners for pricing, customer acquisition, territorial strategy, or bidding.
Scope decomposition
What is shared?
What remains individual?
Which changes affect everybody, and which belong only to one participant?
Without explicit decomposition, shared work quickly becomes contaminated by participant-specific exceptions.
Commitment
Interest is not commitment.
An AI system, marketplace, or matching engine may suggest that two organizations appear compatible. That is not the same thing as either organization agreeing to participate.
Horizontal infrastructure needs an explicit boundary between:
recommendation → negotiation → commitment.
Governance
Who decides changes to the shared scope?
How are costs allocated?
Who owns the resulting assets?
What rights does each participant receive?
What happens if one company creates additional work?
What happens if somebody leaves?
Temporary cooperation still requires governance, even when the coalition itself is lightweight.
Execution visibility
Participants need to see what has been agreed, what changed, who approved it, what remains blocked, and which actions belong to the group versus an individual company.
Observability becomes especially important when no single participant owns the entire process.
Closure
Traditional business software often optimizes relationship retention.
Horizontal cooperation infrastructure must also be good at ending relationships cleanly.
A coalition may successfully complete its task and disappear.
That is not churn.
It is the expected lifecycle.
AI can reduce coordination work, but should not own the relationship
AI is relevant to this architecture because temporary cooperation generates large amounts of information-processing work.
Briefs need to be compared. Requirements need to be normalized. Similarities and differences have to be identified. Candidate partners need to be screened. Scope alternatives need to be prepared. Changes and contradictions need to be summarized.
A systematic review of 67 empirical studies found that disruptive digital technologies, including AI, can affect the initiation, governance, processes, and outcomes of inter-firm collaboration.
That does not mean AI should become the authority inside a coalition.
A safer architectural principle is:
AI can propose. Companies commit.
AI can help identify a possible match.
It should not silently convert that inference into permission to disclose confidential information.
AI can propose a common scope.
It should not bind several independent organizations to commercial terms.
AI can flag inconsistencies.
It should not resolve a dispute simply because one outcome appears computationally efficient.
Horizontal cooperation requires automation, but it also requires explicit decision boundaries.
More cooperation is not the goal
A system designed for horizontal cooperation should not maximize the number of coalitions it creates.
Sometimes the correct result is:
these companies should not work together on this scope.
The shared component may be too small.
The participants may need to exchange information that should remain private.
The customization burden may eliminate the shared benefit.
Governance may become more expensive than the duplicated work.
Competition rules may also constrain what firms can share. The European Commission's Horizontal Cooperation Guidelines explicitly recognize that horizontal cooperation can create benefits while also requiring careful treatment of information exchange and competitive effects.
Good infrastructure therefore needs to make refusal and separation as easy as formation.
From platform thinking to horizontal infrastructure
Horizontal cooperation infrastructure does not imply that every business should become a platform.
Recent Business Horizons research based on 140 platform initiatives shows that established firms can use selected platform mechanisms to solve specific business problems, including transaction inefficiencies, without replacing their entire business model with a platform.
That is a useful way to think about horizontal PRM.
The objective is not to create a giant marketplace for every possible business relationship.
The objective is to apply the right coordination mechanisms where conventional organizational boundaries make useful cooperation unnecessarily difficult.
Sometimes that may require discovery.
Sometimes compatibility screening.
Sometimes shared workflow and governance.
Sometimes only a structured agreement around one reusable piece of work.
The architecture should follow the problem.
A horizontal counterpart to PRM
The term horizontal PRM is useful because the underlying problem really is partner relationship management.
But the relationship is structurally different.
Traditional PRM asks:
How does one company manage its partner ecosystem?
Horizontal PRM asks:
How can independent companies manage a temporary relationship they jointly own?
That difference changes the unit being managed from a permanent partner record to a bounded shared scope.
It changes permissions.
It changes governance.
It changes the role of AI.
And it changes what success looks like.
The successful outcome may not be a larger ecosystem or a longer relationship.
It may simply be several independent companies completing one piece of work together efficiently, preserving their independence, and then separating cleanly.
That is the design space CLAD is exploring.
Produce shared work together. Stay independent.
Sources / Further Reading
- Schotanus, F., & Telgen, J. (2007). Developing a typology of organisational forms of cooperative purchasing. Journal of Purchasing and Supply Management, 13(1), 53–68.
- Bates, S., Harris-Roxas, B., & Wright, M. (2023). Understanding the costs of co-commissioning: Early experiences with co-commissioning in Australia. Australian Journal of Public Administration, 82(4), 462–487.
- Bouncken, R. B., & Vogt, C. (2026). How AI rewires inter-firm collaboration: A review and collaboration rewiring model of disruptive digital technologies. Review of Managerial Science.
- European Commission (2023). Guidelines on the applicability of Article 101 of the Treaty on the Functioning of the European Union to horizontal co-operation agreements.
- National Automobile Dealers Association. NADA 20 Group.
- de Man, A.-P., & Luvison, D. (2019). Collaborative business models: Aligning and operationalizing alliances. Business Horizons, 62(4), 473–482.
- Trabucchi, D., & Buganza, T. (2026). Five business problems platform thinking helps legacy firms solve. Business Horizons.
- Ugriumov, N. (2026). Optimizing Between Firms: Horizontal Cooperation in the Age of AI. SSRN working paper. SSRN record. Zenodo archival record.