Fancy listening to this as an audio? ^Enjoy

I’ve yet to work with a company that had partner attribution figured out. Not one.

They have partners. They have deals that partners touched. They have revenue that probably came through the channel. But when someone asks “what’s the ROI of our partner programme?” the room goes quiet, three people open three different spreadsheets, and the answer depends on who you believe.

The attribution problem isn’t that companies don’t care about measuring partnerships. It’s that they’re using the wrong model for their situation, or worse, they’re using no model at all and manually tagging deals based on whoever shouts loudest.

This piece walks through five attribution models for partner programmes - what each one measures, when each one works, and the specific data infrastructure required to make each one function. No vendor pitches. Just the mechanics.

Why partner attribution is harder than marketing attribution

Before we get into the models, it helps to understand why this is specifically difficult for partnerships.

Marketing attribution has had decades of tooling investment. Every major platform tracks clicks, impressions, and conversions. The data is imperfect, but the infrastructure exists.

Partner attribution has almost none of that. A partner introduces your product in a conversation that happens off-platform. They mention you at a conference. They send an email you never see. They do a technical workshop that convinces a buyer your product integrates well with their stack. None of these touches generate a click. None of them show up in your marketing automation platform.

On top of that, partner activity often overlaps with direct sales activity. An AE is working an account. A partner is also working the same account. A co-marketing campaign is running against the same target list. When the deal closes, who gets credit?

The answer depends on what you’re trying to measure - and that’s where the model selection matters.

The five models

1. First-touch attribution

How it works: 100% of credit goes to whoever created the opportunity. If a partner referred the lead that became the deal, the partner gets full credit. If a direct AE sourced it, the partner gets nothing - even if they were deeply involved in winning it.

What it measures: Origin. Where did this deal come from?

When it works: Early-stage partner programmes (fewer than 50 partners, fewer than 20 partner-sourced deals per quarter) where the primary question is “are partners bringing us new business?” If your leadership team just needs to see that the partner channel is generating pipeline, first-touch is simple and defensible.

What it misses: Everything that happens after the introduction. A partner who refers a lead gets full credit. A partner who spends six weeks doing technical enablement, runs a proof of concept, and convinces the buyer to choose you over a competitor gets zero credit because they didn’t make the initial introduction.

CRM implementation: One field on the opportunity object: “Partner Source.” Populated at deal creation. Locked after stage two. This is a single custom field and a validation rule - you can implement it in an afternoon.

The risk: If you only measure sourced, partners learn to optimise for introductions rather than deal quality. You’ll get more referrals and worse pipeline.

2. Last-touch attribution

How it works: 100% of credit goes to whoever was most active at the point of close. If a partner did the final technical validation that got the deal over the line, they get full credit - regardless of who sourced it.

What it measures: Closing influence. Who helped seal this deal?

When it works: Almost never as a standalone model. I include it because some organisations default to it without realising. If your CRM gives credit to whoever is tagged on the opportunity when it moves to closed-won, you’re running last-touch whether you intended to or not.

What it misses: Everything that happened earlier. The partner who made the introduction six months ago gets nothing. The co-marketing campaign that generated the initial interest gets nothing. All of the top-of-funnel and mid-funnel partner activity disappears.

CRM implementation: The default in most Salesforce configurations. Whoever owns the opportunity or is tagged as the partner at close gets the credit. Often this isn’t even a deliberate choice - it’s just how the system was set up.

The risk: Partners who do sourcing work - referrals, introductions, lead generation - see no credit for their contribution and stop doing it. You hollow out your top-of-funnel.

3. Partner-sourced / partner-influenced split

How it works: Two categories. Partner-sourced means the partner originated the opportunity - without them, the deal wouldn’t exist. Partner-influenced means the partner was involved in progressing or closing the deal, but someone else brought it in.

What it measures: Both origin and involvement, separated into two distinct buckets.

When it works: This is the most common model in B2B partnerships and the one I recommend for most companies between 50 and 500 partner-sourced or influenced deals per quarter. It’s simple enough for sales teams to understand, defensible enough for leadership reporting, and captures partner value at multiple stages.

What it misses: Degree of influence. A partner who does a single co-sell call and a partner who runs a three-month technical evaluation both count as “influenced.” The model doesn’t distinguish between light touch and heavy involvement.

CRM implementation: Two fields on the opportunity object. One checkbox or picklist for “Partner Sourced” (yes/no), one for “Partner Influenced” (yes/no), plus a lookup field linking to the partner account. You’ll need definitions - and this is where most implementations fail. “Sourced” needs a clear test: would this deal exist without this partner? “Influenced” needs a clear test: did the partner perform a documented activity that progressed the deal?

Write those definitions down. Put them in your deal registration rules. Train your AEs on them. If the definitions live in someone’s head rather than in a document, every deal becomes a negotiation.

The risk: Double-counting. If a deal is both “sourced” and “influenced” by the same partner, and you report both numbers to leadership without deduplication, your partner revenue number will be inflated. Decide up front: does sourced supersede influenced? Report them separately, never summed.

4. Multi-touch attribution (weighted)

How it works: Credit is distributed across multiple touchpoints based on a weighting model. Common approaches include U-shaped (40% first touch, 40% last touch, 20% distributed across the middle), W-shaped (30% first touch, 30% lead creation, 30% opportunity creation, 10% distributed), and linear (equal weight across all touches).

What it measures: The full journey. Every partner interaction that contributed to the deal gets proportional credit.

When it works: Mature partner programmes (500+ deals per quarter) with strong data infrastructure, consistent activity logging, and a RevOps team that can maintain the model. If your CRM reliably tracks partner activities - co-sell calls, technical workshops, co-marketing touches, referrals - across the full deal lifecycle, multi-touch gives you the most accurate picture.

What it misses: Offline activity that isn’t logged. If a partner has a conversation at a conference that influences a buyer and nobody records it, it doesn’t exist in the model. Multi-touch is only as good as your activity capture.

CRM implementation: This is where complexity jumps. You need a campaign or activity object that captures every partner touchpoint, linked to the opportunity. You need a weighting model applied across those touchpoints. You need someone maintaining the logic as your partner programme evolves. Most companies implement this through a dedicated attribution platform (Crossbeam, CaliberMind, Dreamdata) or custom Salesforce reports with campaign influence objects.

The risk: Over-engineering. If your data capture is inconsistent - and in most partner programmes it is - a sophisticated weighting model applied to incomplete data produces precise-looking numbers that are precisely wrong. Start with sourced/influenced. Graduate to multi-touch only when your activity logging is reliable.

5. Unified GTM attribution

How it works: Partner activity is treated as one input in a broader attribution model that includes direct sales, marketing, customer success, and product-led signals. No separate “partner attribution” report - partner touches are weighted alongside every other touchpoint in a single revenue attribution system.

What it measures: The true influence of every function and channel on revenue, including partnerships, without treating partners as a separate silo.

When it works: This is the destination, not the starting point. Companies running unified attribution typically have mature RevOps functions, integrated data across CRM, PRM, MAP, and product analytics, and a culture where sales, marketing, and partnerships are measured on shared revenue outcomes rather than siloed metrics.

What it misses: In theory, nothing. In practice, it requires a level of data integration and organisational alignment that most companies haven’t achieved. If your CRM doesn’t talk to your PRM, if marketing and partnerships use different definitions of “influenced,” if your data architecture wasn’t designed to support cross-functional attribution - this model will produce noise, not insight.

CRM implementation: This requires a data layer that unifies touchpoints across all systems. Tools like Crossbeam, HockeyStack, or a custom data warehouse model (Snowflake/BigQuery) feeding a BI layer. Implementation is measured in months, not days, and requires RevOps ownership.

The risk: The gap between aspiration and execution. I’ve seen companies announce they’re moving to unified attribution, buy the tools, run a six-month implementation, and end up with a dashboard nobody trusts because the underlying data was never cleaned first. People, process, data, technology. The sequence applies here too.

How to choose the right model

The model you should use depends on three things: your programme maturity, your data quality, and your organisation’s appetite for complexity.

1. If you’re running fewer than 50 partner deals per quarter and your CRM has basic partner tracking, start with first-touch for sourced deals and add a single “partner influenced” checkbox. That’s Model 1 plus half of Model 3. You can implement it in a week. It’s imperfect and it’s enough to prove the channel is working.

2. If you’re running 50-500 partner deals per quarter with a dedicated partner operations function, the sourced/influenced split (Model 3) is your baseline. Invest the time in writing clear definitions, training sales on how to apply them, and building reporting that separates the two categories cleanly.

3. If you’re running 500+ partner deals per quarter with a mature RevOps function and reliable activity logging, multi-touch (Model 4) gives you a more accurate picture. But only invest in this if your data capture discipline is strong. The model is only as good as the activities logged.

4. Unified GTM attribution (Model 5) is where the industry is heading, but where almost nobody actually is. Build toward it by improving your data integration incrementally rather than trying to implement it as a single project.

The real problem with attribution

Here’s the part nobody talks about.

Attribution is a political problem wearing a technical disguise. The reason partner attribution is hard isn’t that the models are complex - they’re not. It’s that attribution determines compensation, credit, and budget allocation. When the model changes, someone’s number changes. And that makes people defensive.

The AE who doesn’t want to share credit with a partner will find reasons to argue the partner didn’t really “source” the deal. The partner manager who needs to hit a number will tag deals as influenced when the partner’s involvement was a single email. Marketing will count the same deal in their pipeline report using a different model.

• Get the definitions written.

• Get the definitions agreed.

• Get the definitions into your CRM as validation rules, not guidelines.

Then pick the model that matches your maturity and run it.

Attribution doesn’t have to be perfect. It has to be consistent. A simple model applied consistently will tell you more about your partner programme’s value than a sophisticated model applied inconsistently.

Start there.

This isn’t a technical deep-dive into neural networks. This is a plain-language breakdown of what AI is, the different types you’ll encounter, how to assess whether your organisation is actually ready for it, and the questions you should be asking before you sign anything.

What AI actually is

Artificial intelligence is a broad term for technology that can learn from data, identify patterns, and make decisions or produce outputs that would normally require human thinking. That’s it. Everything else is a subcategory.

The confusion starts because “AI” gets used to describe everything from a spreadsheet formula that predicts next quarter’s revenue to an autonomous system that runs your entire customer support operation without human involvement. Those are wildly different things, but they both get called AI.

To cut through this, you need to understand three types that matter right now for business decisions.

The three types you need to know

Predictive AI is the oldest and most established form. It analyses historical data to forecast what’s likely to happen next. If you’ve ever used a lead scoring model, a churn prediction tool, or a demand forecasting system, you’ve used predictive AI.

What it does: looks at past patterns and estimates future outcomes. Which deals are likely to close. Which customers are likely to leave. Which products will sell in Q3. It doesn’t create anything new. It tells you what the data suggests is coming.

Where it works well: forecasting, risk assessment, resource planning, account scoring, pipeline prediction.

Where it falls down: it can only predict based on patterns that already exist in your data. If your data is incomplete, biased, or poorly structured, the predictions will reflect that. Garbage in, confident-sounding garbage out.

Generative AI is what most people mean when they say “AI” in 2026. This is the technology behind tools like ChatGPT, Claude, and image generation platforms. It creates new content - text, images, code, audio, video - by learning patterns from massive datasets and producing original outputs based on prompts.

What it does: produces things that didn’t exist before. Drafts emails. Writes code. Generates marketing copy. Summarises documents. Answers questions in natural language.

Where it works well: content creation, first-draft writing, research synthesis, code generation, customer communication templates, summarisation of large documents.

Where it falls down: it can sound authoritative while being wrong. It generates plausible output, not necessarily accurate output. It has no understanding of your specific business context unless you give it that context. And it raises real questions about data privacy, intellectual property, and quality control that most organisations haven’t answered yet.

Agentic AI is the newest category and the one generating the most hype heading into 2026 and beyond. Unlike predictive AI (which forecasts) and generative AI (which creates), agentic AI acts. It can plan, make decisions, execute multi-step tasks, and use tools - with minimal human oversight.

What it does: autonomously works through complex workflows. An agentic AI system might qualify a lead, check availability, schedule a meeting, send a confirmation, and update your CRM - all without a human touching it.

Where it works well: automating multi-step processes, workflow orchestration, customer support triage, data entry and hygiene tasks, operational monitoring.

Where it falls down: autonomy without guardrails is risk. If an agentic system is working from bad data or poorly defined rules, it will execute bad decisions at scale and at speed. The more autonomous the system, the more important it is that your foundation - your data, your processes, your governance - is solid before you hand it the keys.

The maturity question: where are you actually at?

Understanding the types of AI is step one. Step two is an honest assessment of whether your organisation is ready to use any of them effectively.

Most maturity models use five stages. I’ll simplify them into language that’s actually useful.

Stage 1: Aware. You know AI exists. People in your organisation are using tools like ChatGPT for individual tasks - writing emails, summarising notes, brainstorming. There’s no formal strategy. No governance. No organisational approach. It’s ad hoc and individual.

Most companies think they’re past this stage. Most aren’t. Individual use doesn’t equal organisational readiness.

Stage 2: Experimenting. You’ve run a few pilot projects. Maybe you’ve tested a chatbot, tried an AI-powered sales tool, or used a generative AI platform to produce marketing content. Some pilots worked. Some didn’t. There’s interest from leadership but no formal programme.

This is where the majority of companies actually sit right now. Research suggests most organisations in 2025 and 2026 are stuck here - they’ve had some success with experiments but haven’t figured out how to scale or formalise what they’re doing.

Stage 3: Formalising. You have a defined AI strategy connected to business objectives. There’s budget allocated. You’ve started thinking about data governance, security, and compliance. AI initiatives are coordinated rather than scattered. You’re moving from “we tried some things” to “we’re building a programme.”

Few companies are genuinely here. Many claim to be.

Stage 4: Scaling. AI is integrated into core business processes. It’s not a side project. It’s part of how your teams operate daily. You have governance frameworks, you’re measuring ROI, and you’re making investment decisions based on what’s working and what isn’t.

Stage 5: Optimised. AI is a fundamental part of your operating model. You’re continuously improving, your teams are AI-literate across functions, and you’re using AI to create competitive advantage rather than just efficiency.

Be honest about where you are. The danger isn’t being at Stage 1 or 2. The danger is thinking you’re at Stage 3 or 4 when you’re not - and making investment decisions based on that false assessment.

The litmus test: are you actually ready?

Forget the stages for a moment. Here are seven questions that will tell you more about your AI readiness than any formal assessment.

Can you trust your data? If you asked three people in your organisation for the same number - pipeline value, partner revenue, customer count - would you get the same answer from all three? If not, any AI system you deploy will inherit that inconsistency. AI models are only as reliable as the data they’re trained on and work from.

Do you know what problem you’re solving? “We need to implement AI” is not a problem statement. “Our deal registration response time is too slow and we’re losing partner trust” is a problem statement. If you can’t articulate the specific business problem AI is supposed to address, you’re buying technology in search of a purpose.

Do you have defined processes? AI automates and accelerates. If the process it’s automating is broken, undefined, or inconsistent across teams, AI will automate the dysfunction. You can’t automate what you haven’t defined.

Who owns it? AI initiatives without clear ownership drift. Is this an IT project? A business project? Who is accountable for outcomes? Who decides what gets deployed and what doesn’t? If the answer is vague, the initiative will be too.

Have you thought about governance? Who can access the AI tools? What data are they allowed to use? What are the rules around customer data, intellectual property, and decision-making authority? If you haven’t answered these questions, you’re accumulating risk every day someone uses an AI tool inside your organisation.

Can your team absorb it? Even the best AI tool fails if the people who need to use it don’t understand it, don’t trust it, or don’t change how they work to incorporate it. Adoption isn’t a technology problem. It’s a change management problem.

Can you measure whether it’s working? Before you deploy anything, define what success looks like. Not “we’re using AI” but “we reduced response time by X” or “we increased prediction accuracy by Y.” If you can’t measure the impact, you can’t justify the investment and you can’t tell whether it’s actually delivering value.

If you answered “no” to more than two of those questions, you’re not ready for a major AI investment. You might be ready for small, contained experiments - but you’re not ready to bet operational budget on AI-driven transformation.

That’s not a criticism. It’s a realistic assessment that will save you from joining the growing list of companies that invested heavily in AI and got nothing measurable back. Nearly three quarters of AI investments are currently failing to deliver value. The companies that succeed are the ones that were honest about their starting point.

The sequence still matters

If you’ve read my earlier articles, you know where this ends up. People, Process, Data, Technology. AI is technology. It sits in the fourth position for a reason.

Get your people aligned on what problem you’re solving and who owns it. Get your processes defined and documented so there’s something coherent to automate. Get your data clean, unified, and trustworthy so AI has a reliable foundation to work from. Then - and only then - select the AI technology that serves all three.

This isn’t anti-AI. It’s pro-readiness. The companies that will extract real value from AI over the next two to three years are the ones building the foundation now rather than bolting AI onto an operation that isn’t ready to absorb it.

If you’re honest about where you are, you can build a plan that actually works. If you’re not, you’ll spend money and wonder why nothing changed.

I use a specific version: People, Process, Data, Technology. In that order. Not because it sounds good on a slide, but because every operational failure I’ve ever diagnosed traces back to getting the sequence wrong.

This isn’t a framework for decoration. It’s a diagnostic tool, and it’s the operating lens behind everything I write here. So let me break down what each layer actually means in practice, why most organisations get the order backwards, and what happens when they do.

People

People isn’t about headcount. It’s about alignment.

The question isn’t “do we have enough people” - it’s “are the people we have working toward the same outcomes with the same definitions and the same accountability?”

In most B2B organisations, the answer is no. And it’s not because the individuals are bad at their jobs. It’s because the organisational structure creates competing incentives.

The partnerships team is measured on partner recruitment and certification numbers. The direct sales team is measured on closed-won revenue. Marketing is measured on MQLs. Customer success is measured on retention. Each team optimises for its own number. Nobody is accountable for the connected outcome.

This is where the problems start. A partner registers a deal, but the direct rep is already working the account and doesn’t want to share credit. Marketing runs a campaign that overlaps with a partner’s co-marketing activity, and nobody can tell which touch mattered. The CRO asks for a unified pipeline view and gets three different spreadsheets from three different teams.

The people problem isn’t about skills or capacity. It’s about whether your teams share a common understanding of what they’re building, how success is measured, and who owns what. Until you solve this, every tool you buy and every process you design will be undermined by humans optimising for different goals.

What “fixed” looks like: shared revenue metrics across direct and partner-sourced pipeline. Clear ownership maps for accounts and deals that both direct and indirect teams respect. Compensation structures that don’t punish collaboration. Regular cross-functional operating rhythms where partnerships, sales, marketing, and CS are in the same room looking at the same numbers.

None of this requires a platform. It requires decisions.

Process

Process is where most organisations think they’re strong and where most are actually weakest.

The problem isn’t that processes don’t exist. It’s that they exist in fragments. There’s a process for deal registration and a different process for direct pipeline management. There’s a marketing campaign workflow and a separate partner co-marketing workflow. There’s an onboarding process for new customers and a completely different one for partner-referred customers.

Each process works in isolation. None of them connect.

The result is handoff failures. A partner-sourced lead enters the funnel through deal registration but doesn’t appear in the same pipeline view as direct opportunities. An account is flagged for renewal by CS, but nobody tells the partner who originally brought the deal in. A marketing campaign targets accounts that a partner is already working, and neither side knows until the customer gets two conflicting messages in the same week.

Connected process means that partner-sourced and direct opportunities follow the same qualification criteria, move through the same pipeline stages, and are reported on through the same mechanism. It means that when a deal is registered, the response time is defined and enforced - not dependent on which region the partner sits in or how busy the channel manager is that week. It means conflict resolution has documented rules, not informal negotiations.

Here’s the diagnostic question: can you draw, right now, the end-to-end process from the moment a partner identifies an opportunity to the moment that deal is closed, invoiced, and attributed? Can you draw it without gaps or “it depends” steps?

Most teams can’t. They have pieces. They have workflows inside individual tools. They don’t have a connected process that survives contact with reality across functions and geographies.

What “fixed” looks like: a single pipeline management process that applies to all revenue sources. Defined SLAs for deal registration response. Documented handoff protocols between functions. Conflict resolution rules that exist on paper, not just in the channel manager’s head. Process maps that are maintained, not created once for an offsite and then forgotten.

Data

Data is the layer that determines whether everything above it is real or fiction.

You can have perfectly aligned people and well-designed processes, and if the data underneath doesn’t reflect reality, your reporting is a lie, your attribution is a guess, and your decisions are based on noise.

Most data problems in revenue operations aren’t about volume. Companies have plenty of data. The problem is structural. The data model - the way information is organised, stored, and related across systems - doesn’t match how the business actually works.

Common examples I see constantly:

Your CRM was configured for direct sales. Partner-sourced pipeline requires fields, objects, and relationships that don’t exist in the current data model. So partner data gets forced into fields that weren’t designed for it, or it lives in a separate system entirely with no reliable sync back to the CRM. Either way, the picture is incomplete.

Attribution has no single definition. Marketing counts touches one way. Partnerships counts them another way. Sales ignores both and credits whoever closed the deal. The same opportunity can be “partner-sourced” in the PRM, “marketing-influenced” in the MAP, and “direct” in the CRM. All three systems are technically correct by their own logic. The business has no truth.

Data hygiene is nobody’s job. Fields are populated inconsistently. Regions use different naming conventions. Duplicate records accumulate. The data degrades slowly enough that nobody notices until someone tries to build a report and realises the foundation is rotten.

The diagnostic question for data: if your CFO asked you right now to prove the ROI of your partner programme with a single, defensible number, could you do it? Not a rough estimate. Not a range. A number you’d stake your credibility on.

Almost nobody can. And the reason is almost always the data architecture, not the analysis.

What “fixed” looks like: a data model that explicitly supports partner-sourced, partner-influenced, and direct pipeline as first-class categories - not afterthoughts bolted onto a direct-sales schema. Shared definitions of key objects and fields across all systems. A reconciliation process that ensures PRM data and CRM data tell the same story. Ownership of data quality assigned to a specific function, not assumed to happen organically.

Technology

Technology comes last because it should. Not because it doesn’t matter - it absolutely does - but because technology purchased before the first three layers are solid will underdeliver every single time.

I’ve watched this pattern play out dozens of times. A company decides it needs a PRM platform. They evaluate vendors. They choose one. They implement it. Six months later, engagement is low, the data is messy, the processes are inconsistent, and the company blames the platform.

The platform isn’t the problem. The platform was asked to solve people problems, process problems, and data problems by being a better piece of software. Software doesn’t do that.

Technology amplifies whatever state your operation is in. If your people are aligned, your processes are connected, and your data is clean, a good platform will accelerate everything. It will automate handoffs, surface insights, reduce manual work, and scale what’s already working.

If your people are siloed, your processes are fragmented, and your data is unreliable, a good platform will automate the dysfunction. Faster. At scale. With better-looking dashboards that make the problems harder to see until something breaks badly enough that you can’t ignore it.

The diagnostic question for technology: for every tool in your revenue operations stack, can you articulate what process it supports, what data it depends on, and which teams are accountable for its outputs? If the answer for any tool is “it’s there because we bought it and now we use it,” that tool is probably not earning its cost.

What “fixed” looks like: a technology architecture where every platform has a defined role in the operational system. Integrations that are documented and maintained, not built once and forgotten. Tool selection based on process requirements, not vendor demos. Regular audits of whether the technology is delivering what it was purchased to deliver, with honest answers.

Why the order matters

Here’s the thing that makes this more than a list of four words on a slide.

If you start with technology - and most companies do - you’ve locked yourself into a structure before you’ve defined what the structure needs to support. The platform shapes the process instead of the other way around. The data model follows whatever the tool defaults to, not what the business needs. The people are forced to work around the system rather than through it.

If you start with people - alignment, shared goals, clear ownership - then the process design reflects how the business actually needs to operate. The data architecture is built to support that process. And the technology is selected to serve all three.

Same four components. Completely different outcomes depending on the sequence.

I’m not saying you need to spend a year on each layer before moving to the next. This isn’t waterfall planning. In practice, you’re often working on multiple layers at once. But you need to know which layer is driving the decisions. If a technology decision is driving your process design, you’re going backwards. If a data migration is happening before you’ve agreed on shared definitions, you’re building on sand.

The order isn’t about timeline. It’s about decision hierarchy. When there’s a conflict - when the tool can’t support the process you need, or the data model doesn’t fit the platform - which layer wins?

People, Process, Data, Technology. The first one in the sequence always wins.

The honest part

I’ll be straight with you. This framework doesn’t sell well. Nobody gets promoted for presenting “we need to align incentives and fix our data model” at the quarterly business review. Platforms get bought because they look like progress. They come with timelines and milestones and implementation partners who produce status reports.

Alignment work is invisible until it works. Process documentation is boring until the first time a deal conflict gets resolved in hours instead of weeks. Data architecture is thankless until the CFO asks for partner ROI and you can actually answer the question.

The companies that get this right aren’t the ones with the best tools. They’re the ones willing to do the slow work in the right order. Everything I write here is built on that conviction.

It wasn’t.

On paper, the partner program looked fine. Thousands of partners across multiple geographies. A portal. Training materials. Certification tracks. Deal registration. The slide deck for the board showed a growing ecosystem. The reality was that partner engagement sat at 32%. Two thirds of the partner base was effectively dormant. They’d signed up, maybe logged in once, and then disappeared.

The company was spending money on a partner program that most partners weren’t using, selling a migration that most partners weren’t equipped to deliver, and reporting on ecosystem growth that wasn’t real.

I had a team of 15 spread across multiple time zones and a mandate to fix it.

The first thing I did was stop looking at the technology

Everyone wanted to talk about the PRM platform. The existing one was clunky, the UX was poor, partners complained about it. The obvious move - the one people kept pushing for - was to rip it out and replace it.

I didn’t start there.

I started by talking to partners. Not surveying them. Talking to them. What I found wasn’t a technology problem. It was a series of connected operational failures that no platform could fix on its own.

Partners didn’t understand the SaaS migration story well enough to sell it. The enablement materials were built for the internal sales team, not for external partners who had different customers, different objections, and different sales motions. Partners were being asked to sell something they’d never been trained to position.

Deal registration was a black hole. Partners would register a deal and hear nothing for weeks. When they did hear back, they’d often discover that a direct sales rep was already working the same account. There was no clear process for resolving conflicts, and no trust that the system would protect the partner’s investment of time.

Attribution was a mess. Marketing was running campaigns that overlapped with partner activity, and nobody could separate the two in the CRM. When a deal closed, the question of whether it was partner-sourced or partner-influenced or purely direct was answered by whoever had the loudest voice in the room, not by data.

The CRM wasn’t aligned to the go-to-market motion. Salesforce had been configured for the old world - on-prem, direct sales, single-touch attribution. The data model didn’t reflect the reality of partner-sourced pipeline. Fields were inconsistent. Objects were misused. Reporting was unreliable because the underlying data architecture was unreliable.

None of these were technology problems. They were people, process, and data problems that had been accumulating for years while successive platform decisions papered over them.

What we actually fixed

We did eventually replace the PRM. But that was step four, not step one.

Step one was the data. We rebuilt the CRM architecture to support partner-sourced and partner-influenced pipeline alongside the direct motion. That meant new objects, new fields, clear definitions of what counted as partner-sourced versus partner-influenced versus direct. We standardised the data model across regions so that a deal registered in EMEA looked the same as one registered in North America. Without this, nothing else would have worked.

Step two was the process. We redesigned deal registration to guarantee response times. We built conflict resolution rules that were documented and enforced, not negotiated deal by deal. We created a single pipeline management process that applied to both direct and partner-sourced opportunities - same stages, same criteria, same reporting. Partners stopped being a separate, lesser pipeline and became part of the revenue operation.

Step three was the people. We rebuilt the enablement program specifically for partners. Not a copy of the internal training. Materials built for how partners actually sell - their customers, their language, their objections. We ran targeted enablement for the SaaS migration story so partners could position it with confidence. We also aligned internal incentives so that direct sales reps weren’t penalised for working with partners on the same account.

Step four was the technology. Once the data model was solid, the processes were defined, and the people were trained and aligned, we implemented a new PRM platform. The platform worked because it was built on a foundation that actually made sense. It wasn’t trying to compensate for broken data or undefined processes. It was accelerating operations that already functioned.

Within two years, partner engagement went from 32% to 80%. We achieved eight consecutive quarters of revenue growth. The ecosystem stopped being a cost centre that produced slide decks and became an operational channel that produced attributable revenue.

What I actually learned

The obvious takeaway is that the fix worked. But the thing I keep coming back to isn’t the result. It’s the pattern.

Every organisation I’ve worked in or consulted for since has had some version of the same problem. The technology gets bought first. The process gets retrofitted to match the tool. The data gets forced into a structure that doesn’t reflect reality. The people are the last thing anyone thinks about. And then everyone wonders why the system doesn’t deliver.

People. Process. Data. Technology. In that order. It’s not complicated. But it is hard, because it means doing the slow, unglamorous work before you get to the exciting platform implementation. It means fixing the CRM data model before you buy the PRM. It means defining deal registration rules before you automate them. It means training partners on how to sell the thing before you measure whether they’re selling it.

Most companies skip to the technology because it feels like progress. It looks good in the quarterly update. A new platform is a deliverable. Fixing your data architecture is invisible until it starts working.

The companies that get ecosystem operations right are the ones willing to do the invisible work first. That’s what this publication is about.

If you’ve read the first two articles - the Start Here and What Is Ecosystem Orchestration - you already know the thesis.

This is what it looks like when you apply it to a real programme in a real company with real constraints.

The numbers are nice. But the lesson is the sequence.

Subscribe now

The partnerships people are talking about ecosystem orchestration. They mean coordinating partner networks - onboarding, enablement, co-selling motions, deal registration, marketplace strategy. Their version of orchestration is about getting partners to do things.

The RevOps people are talking about revenue orchestration. They mean connecting sales, marketing, and customer success tools into unified workflows. Automating handoffs. Cleaning data pipelines. Their version of orchestration is about getting systems to talk to each other.

The GTM engineers are talking about go-to-market orchestration. They mean building the operational infrastructure that turns strategy into repeatable execution. Signal routing, intent data, automated outreach sequences. Their version of orchestration is about getting motions to scale.

All three groups are right about their piece. None of them are talking to each other. And that gap - between the partner motion, the revenue operation, and the go-to-market execution - is where most B2B companies are quietly losing money.

The problem with partial orchestration

Here’s what I see over and over again.

A company invests in a PRM platform to manage their partner ecosystem. They get partners registered, trained, and certified. They run co-marketing campaigns. They build a portal. The partnerships team reports on partner recruitment numbers and certification rates. Somebody makes a slide about ecosystem growth.

Meanwhile, the RevOps team can’t see partner-sourced pipeline in the CRM because the data doesn’t flow cleanly between the PRM and Salesforce. Deal registration exists, but attribution is a mess. Marketing is running campaigns that overlap with partner activity, and nobody can tell which touch actually influenced the deal. The CRO asks for a report on partner ROI and gets three different numbers from three different teams.

The GTM engineering team has built automated sequences for direct sales that completely ignore the partner channel. Their orchestration layer routes leads, triggers outreach, and scores accounts - but only for the direct motion. Partners exist in a parallel universe.

Each team has orchestrated their piece. The whole system is still broken.

This is the norm, not the exception. I’ve worked inside organisations where the partner team, the RevOps team, and the GTM team each had their own tools, their own data sources, their own definitions of what counts as a qualified opportunity, and their own reporting dashboards that told completely different stories about the same quarter.

What ecosystem orchestration actually means

Ecosystem orchestration - the way I use the term - is not partner management. It’s not revenue automation. It’s not GTM workflow design. It’s the discipline of connecting all three into a single operational system that produces attributable, repeatable revenue.

That means the partner motion, the revenue operation, and the go-to-market execution share the same data foundation, follow aligned processes, and operate within a governance structure that prevents the kind of drift I just described.

Four things have to be true for this to work:

The people are aligned. Partner teams, RevOps, sales, marketing, and customer success are not operating in silos with separate objectives. There is shared accountability for revenue outcomes, not just activity metrics. The partner leader isn’t measured solely on recruitment numbers while the CRO is measured on closed-won. They’re looking at the same pipeline.

The processes are connected. Deal registration feeds into the same pipeline management process as direct sales. Partner-sourced and partner-influenced deals follow the same qualification criteria. Handoffs between partner activity and direct sales activity are defined, documented, and enforced. There isn’t one process for direct and a different, lesser process for channel.

The data is unified. This is where most of it falls apart. If your PRM data doesn’t reconcile with your CRM data, you can’t attribute revenue to partners with any confidence. If your marketing automation platform can’t distinguish between partner-influenced touches and direct touches, your attribution model is fiction. Ecosystem orchestration requires a data architecture where partner activity, direct activity, and customer signals live in the same system of record - or at minimum, are reliably integrated.

The technology serves the first three, not the other way around. I’ve watched companies buy a PRM, a revenue orchestration platform, an intent data tool, and a co-selling platform - then wonder why they still can’t produce a reliable partner ROI number. The tools aren’t the problem. The tools were bought before the alignment, the process, and the data architecture were in place. This is the most common and most expensive mistake in the space.

People. Process. Data. Technology. In that order. Skip a step and you’ve bought yourself an expensive reporting problem.

Where AI fits - and where it doesn’t

I can’t write about operations in 2026 without talking about AI, and I don’t want to. AI is going to change how ecosystem orchestration works. Some of that change is already happening. But the way AI is being sold into this space right now deserves some honest scrutiny.

The promise is compelling. AI agents that automate partner onboarding. Predictive models that score partners based on future revenue contribution rather than historical performance. Automated deal routing that matches opportunities to the right partner based on capability, geography, and past win rates. In-workflow enablement that surfaces the right content at the right moment instead of pointing partners at a static LMS.

Some of this is real and useful today. Vendors using AI for training localisation and customer success support are reporting measurable increases in partner-sold revenue compared to companies without those capabilities. Agentic AI systems that take action and automate workflows across partner ecosystems are accelerating into production.

But here’s where I get cautious.

AI applied to a broken foundation doesn’t fix the foundation. It automates the brokenness faster. If your partner data doesn’t reconcile with your CRM, an AI model trained on that data will produce confident-sounding garbage. If your attribution model is built on incomplete data, a predictive layer on top will give you precise-looking forecasts that are precisely wrong.

AI is not simplifying enterprise technology. It’s shifting where complexity lives. While AI reduces effort at the surface level, it introduces new layers of operational complexity beneath it. Data is fragmented across systems. Integration requires careful orchestration.

That last point is critical and it’s the one most AI vendors skip past in the demo. The prerequisite for AI to deliver value in ecosystem operations is exactly the same foundation I’ve been describing: aligned people, connected processes, clean unified data, and technology that serves all three. AI doesn’t replace that foundation. It depends on it.

I’m not anti-AI. I use it in my own work. I advise clients on where and how to implement it. But I’ve watched enough organisations bolt AI onto broken systems and call it transformation. That’s not transformation. That’s automation of existing dysfunction with a better user interface.

The companies that will get real value from AI in their ecosystem operations are the ones that fix the plumbing first. Get the data clean. Get the processes aligned. Get the teams working from the same definitions. Then layer AI on top and let it do what it’s actually good at - finding patterns in good data, automating repetitive workflows, and surfacing signals that humans would miss.

That sequence matters. Most companies are trying to do it in reverse.

Why this matters now

There’s a reason ecosystem orchestration is becoming urgent rather than optional.

The buying environment has changed. Enterprise purchases now involve multiple vendors, multiple partners, and multiple decision-makers. The average enterprise technology purchase touches three to five different vendor solutions. Linear, single-vendor sales motions are less and less effective. The companies that can orchestrate multi-partner motions - with clean data, clear attribution, and aligned execution - will win the deals that matter.

75% of business leaders now acknowledge ecosystem partnerships as a key driver of their growth strategies. But acknowledging it and operationalising it are very different things. Only 10-20% of partners drive meaningful revenue in most B2B technology companies. The rest consume resources without measurable impact - not because those partners are bad, but because the operational infrastructure to activate them doesn’t exist.

That’s the gap. Not a strategy gap. Not a technology gap. An orchestration gap.

What comes next

This is what Ecosystem Revenue Dynamics is about. Not theory. Not tool reviews. Not vendor-sponsored content dressed up as thought leadership.

I write about how to build the operational systems that make ecosystems actually produce revenue. How to fix the data. How to align the teams. How to design processes that work across direct and indirect motions. How to evaluate AI honestly. How to prove partner ROI to a CFO who doesn’t take your word for it.

If that sounds useful, subscribe. The articles come weekly, and they’re built for people who have to make this stuff work - not people who just have to talk about it.

I’ve spent nearly two decades inside the systems that run B2B revenue. CRM implementations, partner ecosystems with thousands of partners, GTM transformations, country-scale migrations, and the operational mess that sits between strategy decks and actual execution.

I started as an engineer. I’ve been a solution architect, a program manager, a pre-sales director, an enablement leader running 70 people across three continents, and a senior director of global revenue operations responsible for channel ecosystems and SaaS transformation.

I’ve built PRM platforms, configured CPQ systems, restructured CRM orgs, and spent more hours than I’d like to admit fighting the gap between what a system is supposed to do and what it actually does when real data hits it.

I now run ERD, a consultancy focused on ecosystem revenue engineering for B2B SaaS. I work with private equity firms and enterprise companies to fix the operational infrastructure that their revenue depends on.

That’s the short version. Here’s why it matters for this publication.

What this Substack covers

Ecosystem Revenue Dynamics writes about four things:

Ecosystem orchestration - how partner programs actually generate attributable revenue, not just logos on a slide. Most companies have partners. Very few can prove what those partnerships are worth. I write about building the operational infrastructure that changes that.

Revenue operations - team structure, data alignment, system architecture, and the foundational work that has to happen before any tool does what the sales rep promised. If your CRM is a mess, your reporting is a lie. I write about fixing that.

GTM engineering - the operational backbone of go-to-market. Not strategy. The actual build. How do you connect the systems, automate the handoffs, and create a motion that scales without breaking?

AI in operations - where it helps, where it’s theatre, and how to evaluate it honestly without getting sold a vision your data can’t support.

The thread connecting all four is a lens I come back to constantly:

People, Process, Technology, Data

And in that order.

Most teams start with technology and work backwards. That’s why most implementations underdeliver.

What you won’t get here

I don’t sell tools. I don’t have vendor partnerships that influence what I recommend. If a platform is good, I’ll say so. If it’s overhyped, I’ll say that too.

I don’t write strategy theory. If you want frameworks that look good on a whiteboard but never survive first contact with your data, there are plenty of places to find those.

I don’t write for people who want to be told everything is fine. If the foundation is broken, I’ll say the foundation is broken.

Who this is for

You work in or around revenue operations, partnerships, GTM, or the operational side of B2B SaaS. Maybe you’re an IC building the systems. Maybe you’re a leader trying to figure out why the systems you bought aren’t delivering. Maybe you’re a founder who knows something is off but can’t diagnose where.

If you’ve ever asked “why can’t we prove what our partners are worth” or “why does nobody trust our data” or “we bought the tool, why isn’t it working” - you’re in the right place.

What to expect

At least one article a week. Free. No paywall games at this stage.

Each piece will be grounded in practice, not theory. Specific problems, specific thinking, occasionally specific opinions that not everyone will agree with.

That’s the point.

If you find value here, subscribe. If something resonates, share it with someone fighting the same problems. A

nd if you want to talk about your specific situation, ERD does consulting and advisory work - that’s what the site is for.

For now, this is the publication. Welcome.

Subscribe now