They Want an Answer.

A partner wants to know whether a deal registration has been approved, what price applies to a configuration, whether a rebate has been paid, or what happened to the ticket they opened for a customer last week. Read how AI partner experience is changing the game.

For most of the last fifteen years, getting that answer meant going to a portal: logging in, finding the right section, figuring out which version of the program rules applied, and re-entering information the vendor likely already had somewhere else. Then, in many cases, the partner still had to wait for someone internally to confirm it.

Partners learned to use portals because they had to. That is starting to change. Some vendors already let partners ask these questions from inside their CRM, inbox, Slack, or AI assistant, and the answer comes back there without another portal, another navigation path, or another learning curve.

That is the more important shift. Partners will increasingly engage with vendors from the tools where they already work, rather than the places vendors ask them to log into. That changes how channel leaders should think about partner experience.

The portal isn’t losing to a better portal. It’s AI partner experiences.

For years, companies have redesigned partner portals with new navigation, better search, cleaner dashboards, SSO, and more personalization. Yet usage still falls short of what most teams want. This is no longer primarily a UX problem. The larger issue is structural.

Deal registration lives in one system, enablement in another, incentives in a third, and onboarding in three more. So, even when the portal looks polished, partners still move between processes that don’t know about each other and do not share context. That causes the same company details to be entered twice, and contacts are created multiple times. Information already provided during enrollment gets requested again during compliance. Eventually, someone waits for a human to check a box.

You can see this clearly during onboarding (see our post on how we’ve simplified the partner and operational experience here). Where programs often lose momentum with partners in the first 90 days. It is easy to blame training, engagement, or content, and sometimes that is true. But often the answer is simpler: there are too many handoffs.

After two days at Catalyst 26, this was heard repeatedly from people who run partner programs. Nobody seemed especially attached to the traditional portal. One participant had come specifically to understand how other companies were managing theirs so they could decide what their own portal strategy should become. Another company, whose product is itself a partner portal, spoke openly about how the traditional portal model is changing because vendors have to meet partners where they already work. One company put it especially well: their website is for information. AI-driven experiences are for getting things done. That distinction stood out to many.

Several companies are now building official integrations and plugins for tools like ChatGPT and Claude. The point is not simply to say they have an AI strategy. It is control. If a partner asks ChatGPT about your program today and you provide no authoritative source, the answer may come from model training, something found on the web, an outdated document, or some combination of all three. An official integration gives the vendor a way to say, “This is the answer.” Get it from us.

Smaller organizations are already taking this further and delivering parts of the partner experience through Slack or WhatsApp. Larger companies tend to remain portal-first, not necessarily because they believe the portal is the future, but often because replacing what already exists is expensive. The same idea surfaced on the Catalyst main stage in another form: programs want to scale further down-market, but they cannot put a partner manager behind every partner.

If every question, approval, enablement request, and status update requires an internal response, the cost of servicing the long tail becomes larger than its value. Instead, conversational and self-service experiences change that equation. That is where the portal conversation becomes much more interesting.

It’s an integration decision, and it’s segmented.

Portals likely won’t disappear, but their role gets smaller. The portal becomes more of an administrative backend for registration, contracts, compliance, and configuration, and perhaps the central knowledge repository where information is collected, maintained, and enriched. The experience starts moving elsewhere. Where it moves depends on the partner, and that is where segmentation matters.

One company described using AI-heavy-driven workflows for the long-tail partners while keeping humans in place for their highest-value partners. However, it is not inconsistent; it is segmenting the partner experience. It has been happening in sales and customer success for decades. Not every account gets the same engagement model, so why should every partner?

For some partners, an MCP endpoint may be perfectly adequate. Other partners, a plugin inside an AI assistant makes more sense. For strategic partners, a proper integration directly into their CRM or PRM can easily be worth the investment. The important thing is understanding where the partner already works: what tier they belong to, what technology they use, what they are already integrated with, and how much business flows through the relationship.

MCP is a useful example. A Partnership Leaders’ survey found that 86% of companies already have an MCP initiative underway. At one Catalyst table with ten companies, every company was building one. That does not mean every partner relationship suddenly needs a sophisticated MCP strategy. In fact, one of MCP’s advantages is the opposite. It is relatively easy to expose a useful set of capabilities without requiring a major integration project on both sides. For the long tail of partners, that may be enough. For a small number of strategic partners generating significant revenue, a dedicated integration probably still makes sense. Both things can be true.

The layer is being built. Partnerships mostly aren’t building it.

Official plugins for the assistants partners already use sit somewhere in the middle, offering more control than simply hoping a general-purpose model finds the right answer, with less commitment than building a dedicated integration for every partner.

But notice what all of these options have in common. This is no longer really portal work. It is integration work. You are connecting your program and its data to whichever surface the partner happens to use. The portal becomes one surface among many, rather than necessarily being the front door.

An instant wrong answer is worse than a slow one.

Here is where it gets uncomfortable.

A portal, for all its faults, exposes records: you see the deal, the field, and the number. If something looks wrong, at least someone might notice. An AI assistant works differently. You ask a question, and it gives you an answer, usually one answer. If the underlying data says the margin is 18% when it should be 12%, the assistant doesn’t necessarily know something looks suspicious. It simply and confidently tells you 18%.

Now you have made incorrect information easier to access. Every MCP server, plugin, assistant, and integration ultimately has the same dependency: the data underneath it. Adding AI does not fix bad data. In some ways, it removes one of the last places where bad data was visible.

Where do the wrong answers come from?

Most partner organizations do not have one system supporting their partners and partner experience. They have many. Deal registrations live in one place, onboarding somewhere else, incentive claims in another platform, distributor data arrives through feeds, enablement sits in an LMS, and contacts are in a CRM. The usual response has been to bring all of this into an MDM platform, data warehouse, or BI layer.

That is useful, but there is an important difference between seeing inconsistent data and controlling it. A reporting layer gives you a consolidated view. Still, it does not necessarily decide which record is correct, resolve duplicates, define how conflicting records survive, or drive the operational workflows that still depend on the original systems. So you end up with a beautiful dashboard showing inconsistencies that exist everywhere underneath it.

When AI arrives on top, it is ready before the data is. Here are four versions of that problem that come up again and again in partner programs.

The dashboard nobody trusts

The company has partner performance reporting, but important decisions still happen in spreadsheets. Sometimes the same reseller exists three times across distributor feeds, with a slightly different name, different IDs, or different spelling. To a human, they are obviously the same company. To the system, they are three companies. No model can correctly aggregate what it doesn’t know is the same entity.

Attribution that overstates

Incentives are based on partner contribution, but what if the field does not trust the attribution? One reason is surprisingly simple: the same deal appears more than once. The deal might be counted at the distributor level and again at the reseller level, inflating partner contribution and creating conflict about where to invest. Before a model can use that data reliably, the underlying system needs to know that both records represent the same transaction.

AI assistants providing incorrect program terms.

This was shared at Catalyst: a partner asks a general-purpose AI assistant about a vendor’s eligibility criteria, but the vendor has no official integration. The model finds as much information as it can and produces a plausible-sounding answer. The partner plans around it, the vendor later applies the actual program terms, and now both sides have a problem.

The first failure is having no source of truth. The second is more subtle: you build the official integration, but your retrieval layer contains two versions of the same program document, one current and one outdated, without a rule that determines which one wins. So the model chooses. Air Canada’s chatbot case is probably the best-known public example of how expensive that kind of inconsistency can become: the chatbot described a refund policy that conflicted with the airline’s actual policy, and the airline was ultimately held responsible for what its chatbot told the customer.

The lesson is not “do not use chatbots.” It is that putting a conversational layer in front of inconsistent information does not remove the inconsistency.

Partner scoring that recommends the wrong partners

You build a model to identify the best partners for a new motion. The top of the list surprises everyone who knows the partners well. Why? The labels the model learned from were built on the same distorted data it is now predicting from. It is not learning who performs. It is learning who reports cleanly.

This wasn’t a fringe view.

Omdia estimates that 98% of the world’s business data has never been trained into a large language model, and that 83% of it sits in cold storage. In their 2025 AI Market Maturity survey, lack of data or data quality issues appears third among customers’ AI adoption barriers, and integrating AI with legacy systems appears fifth.

From the main stage to the floor, we heard that agentic workflows cannot function without a solid and integrated data foundation. Enterprises need an orchestration layer that acts as the control plane, governing what AI touches and preventing shadow deployments. At our roundtable discussions, the consensus was clear: data, process, and policy are prerequisites, not the follow-up. Security companies were the sharpest on this, raising data ownership and sovereignty as a condition of applying AI at all.

One company had done the work. They built a knowledge layer over their internal systems and made it accessible through an off-the-shelf AI chat they did not build themselves. Agents take actions, and humans trigger them. When they described what made it possible, they did not really talk about the chatbot. They talked about the layer.

Clean up the data first, then create the layer.

The fix has two parts. However, the first is the one nobody wants to buy.

Why does no one invest here? Because cleanup does not feel like progress.  It is identifying the data in each system, standardizing formats across them, matching records deterministically where shared IDs exist and with fuzzy logic where they don’t, and deciding survivorship rules when records conflict. It means building translation tables so each system’s identifiers map to the others, mapping schemas across transaction feeds that were not designed to work together, and treating stewardship as an ongoing function rather than a project done once and left unchanged. It is the least glamorous work, but the reason everything else works.

The second part is the orchestration layer. It’s a single source of truth for other systems to draw from, including the MCP server, the plugins, the integrations, and the internal tools your team uses. Governance lives here, not inside each integration. It defines what gets exposed to each partner segment, what gets evaluated before it reaches anyone outside the company, what an agent is allowed to act on, and what still needs a human to trigger it.

The benefit runs both ways. The internal team asking about a partner gets the same correct answer the partner gets asking about their deal, because it is the same answer from the same place.

The market has already priced this. Omdia puts partner-led AI services at $85 billion in 2026, growing to $347 billion by 2031, and data readiness and foundations is one of the named categories inside that spend. The work has a line item. Most programs are still treating it like plumbing.

Back to the partner

They ask a question and get a correct answer inside the tool they were already using. They never find out a crosswalk table exists, and they never should.

Every partner program is now answering two questions, whether it means to or not: where partners get the answer, and whether it’s right. Most of the investment going into AI right now targets the first question. The second one decides whether any of it works.

This is the work we do.