Article

What a Functional Experience Layer Looks Like

I spent a year supporting a partner portal that everyone called a portal, but nobody would actually call it an experience. Partners signed in, hunted through a content library for the asset they needed, usually failed, and emailed us instead. Our team's real job wasn't running the portal. It was being the search function the portal didn't have.

I wanted to share my thoughts on why this happens and what actually fixes it.

The portal that's really a content dump

Here's how you know which one you have. Log in as a partner and ask a simple question: what should I do next? A filing cabinet can't answer that. It shows you everything, sorted by category, identical for every partner who logs in. A reseller, a managed-service partner, and a brand-new signup all see the same wall of folders.

That's the tell. The content dump puts the burden of figuring out what's relevant entirely on the partner, and when they can't, that burden rolls downhill to you as a support ticket, an access request, or a "where do I find" email. The portal didn't reduce your workload. It generated it.

What "functional" actually means

A functional experience layer answers the question the filing cabinet can't. It's role-aware, so what a Gold-tier reseller sees is materially different from what a new ISV sees, in real time, without anyone building separate sites. It's contextual, surfacing the next action for that partner right now instead of a static library they have to dig through.

It also gates correctly. Assets are delivered based on tier and consent automatically, so a partner only ever sees what they're actually entitled to. "Functional" isn't a nicer UI. It's the portal doing the work your team currently does by hand.

What it replaces

This is the part worth being concrete about, because it's your week. A real experience layer replaces the content library nobody can navigate. It replaces the access-request email, because entitlement is enforced automatically. It replaces the status-chasing, because a partner can see where their request is without asking you. It replaces the tribal knowledge in your head, the part where partners email you specifically because you're the one who knows where things live.

That work doesn't move to someone else. It stops being generated.

Why the experience layer can't fix itself

An experience layer can only be role-aware if something upstream knows the partner's role. It can only gate by tier if tier status is accurate and current. It can only personalize if there's a resolved partner record to personalize against. The portal renders exactly what the layers beneath it hand up.

So when a portal behaves like a filing cabinet, it's usually not the portal's fault. The fix starts one layer down, in the data the experience is supposed to read from, which is also why a redesign that only touches the front end tends to ship a prettier filing cabinet.

The question isn't whether the portal looks modern. It's whether it knows who a partner is and what they should do next when they log in, or whether it still sends them to you. This is exactly what our Five-Layer Partner Ecosystem Architecture framework explores.

More thinking like this from our team.

AUTHOR

Andy Sharma

Business Architect, Valorem Reply