Turning Partner Operations into a Self-Service Digital Experience

#The problem, as it actually presented

The brief arrives as a portal request, and at that point it is almost never a portal problem. What people say is that the partner team is drowning, or that dealers keep ringing the same three people, or that a shared mailbox has quietly become the operating system of the entire channel.

Underneath, the shape is consistent. A manufacturer sells through accredited dealers and installers, and their requests all land in one mailbox staffed by two or three people who know the answers. Nearly every answer already exists in Salesforce.

The difficult part of the conversation is that the mailbox works. It works because the people in it are good, and it keeps working until one of them takes leave, or somebody asks how long a warranty claim actually takes and nobody can answer, because the claim lived in a thread.

#What we designed, and why

The tasks came out of the mailbox, not out of the workshop

Ask the business what a partner portal should contain and you get the organisational chart back. Marketing wants an asset library. Product wants a launch feed. Training wants a learning path. Somebody wants a discussion forum, and nobody can name the two partners who would post in it.

So the ranking is built from evidence instead. Twelve months of mailbox subject lines, the case reasons where cases were logged, and the notes from the partner operations phone line. Group them by the task the partner was trying to finish, not by the internal team that answered, and rank by volume.

The result is reliably dull and reliably useful. Four tasks carry most of the traffic: check an order status, get a copy of an invoice or compliance certificate, raise a warranty claim and track it, and confirm accreditation before registering a deal. The asset library appears some way down. The forum does not appear at all, because nobody has ever emailed asking for one.

This is uncomfortable to present, which is why it gets presented before anybody draws a wireframe.

External sharing is the build

The visible part of a portal is the theme. The part that decides whether it can exist at all is the external sharing model, and on a dealer network the stakes are plain: two dealers in the same region compete. If one can see the other's orders, that is not a rendering defect to triage next sprint. It is a disclosure of commercial information to a competitor.

That framing changes the sequencing. External access gets designed and negatively tested before anything is styled.

Three things did the work. External organisation-wide defaults were set object by object and recorded separately from the internal ones: an object that is read-only inside the organisation can and should be private outside it. Each exposed object then stated how access is granted: through the role hierarchy beneath the account, or a sharing set matching a field on the record to the user. And every externally exposed object had to carry that relationship, populated, on every record.

The last one is where the surprise usually sits. The warranty claim object had been built for internal use, and it reached the account through its parent rather than directly. Internally that is fine. Externally there is nothing for the sharing set to match on, and retrofitting the relationship after go-live is a data exercise rather than a configuration change.

Licence type against what those users actually do

The external licence type is chosen early, usually in a commercial conversation, on the only information available at that point: how many partners there might be and what each one costs. Capability gets discussed in general terms and the number wins.

The correction takes half an hour. Before the licence conversation, write the verbs. A dealer will read an article. Check an order. Download a document. Raise a claim. Own the claim they raised. See a claim a colleague at the same dealership raised. Register a deal, which means working an opportunity record. Manage their own users when a fitter joins or leaves.

Those verbs sort themselves into tiers immediately. Read-and-log at scale sits at one end. Owning records, collaborating within your own organisation and working a pipeline sits at the other, and costs meaningfully more per user for good reason. Deal registration was the verb that settled it here, because registering a deal is not a read.

The mismatch this avoids is common and it surfaces late. A portal is bought at the tier that suited the original brief, the work being done drifts upward over a year or two, and nobody notices until renewal, when the commercial conversation and the architectural one arrive together. Confirm current entitlements with Salesforce rather than working from a table somebody saved two years ago; the detail moves.

Knowledge that answers the question the partner asked

Partner content usually arrives from the internal wiki, and internal content describes. It states a policy in the order the policy was written, using the product name the factory uses.

A fitter in a roof cavity needs the answer in the first two lines, in the words they would have typed. The rewrite is mechanical. Title the article as the question. Put the answer first and the qualifications underneath. Write one article per question rather than one per policy document. Where the answer is currently a PDF, accept that the task will not complete on a phone and rewrite it as a page.

Then surface the article against the task rather than behind a search box. An article reachable only by searching is an article most people will not reach, and the ones who reach it will have typed the customer word rather than the internal one.

What should stay a phone call

The portal was scoped to remove repetition, not to remove people. Some things were deliberately left off it.

Pricing disputes, credit holds, anything where the answer is a negotiation, an unhappy end customer, and any warranty claim where the assessment is genuinely contested. Those conversations need judgement, tone and somebody with authority to decide, and putting them behind a form produces a worse outcome slowly instead of a better one quickly.

So every task page carries a phone number and the name of the account manager, and the escalation path from a case is designed rather than left as a fallback. A partner who cannot finish a task in the portal should reach a person in one step, and should not have to describe the problem again from the start.

#Implementation

The sequence matters more than the components.

External access model first, before any theming. Defaults per object, grant mechanism per object, relationship fields confirmed as populated, guest scope written down as a named list somebody has read out loud.

Then the external test users, in the same sprint as the first component. One per licence type and per persona, including two dealers who should not be able to see each other. Every review of the site from that point happens logged in as one of them. A team reviewing as administrators is making decisions on evidence that does not apply.

Then the four tasks, one at a time, instrumented. Entry and completion events per task, with completion fired from the record that proves it happened rather than from arrival at a confirmation screen.

Then knowledge, then escalation, then the theme. The theme is the part everybody can see and the cheapest part to change. A rebrand is a sprint. The sharing model is neither.

#The decisions that were contested

Keeping the mailbox open. The tidy plan closes it on go-live. We argued to leave it open with an auto-reply pointing at the portal, and to read what still arrived. That residue is the best available list of what the portal does not yet do, and switching the mailbox off destroys the only feedback channel that was ever honest.

Refusing cross-dealer visibility inside a group. Several multi-site dealer groups asked for one login that could see every site's orders. The external account hierarchy supports that shape, and we still made it an explicit, per-group decision with the group's own written request behind it, rather than a default. Visibility across accounts is exactly the thing that must never happen by accident.

Not building the community forum. It had a sponsor and it had slides. It did not appear anywhere in twelve months of mailbox traffic, and a forum with no posts is worse than no forum, because it advertises that nobody is here.

Leaving warranty assessment off the portal. Partners can raise and track a claim. They cannot see the internal assessment notes while it is in progress, because half of those notes are working thinking and reading them mid-flight produces an argument rather than an outcome.

#What changes

The outcomes worth claiming here are operational. They follow from the design rather than from effort.

The second-order effect is the one the channel team notices. The conversation with a dealer stops opening with a status question and starts somewhere further along, because the status was already answered before the call.

#Where Experience Cloud is not the answer

This design assumes the portal exists to expose data and processes already held on the platform to a known, accredited audience. That describes most partner portals, and where it holds, configuring beats building, because the sharing model, the identity layer and the release upkeep come with the licence rather than becoming yours to own forever.

It stops holding in three places. If the portal is the product partners pay for rather than a channel to reach you, it needs its own release cadence and a custom build is defensible. If the audience is consumer scale, per-user licensing is the wrong instrument. And if there is a genuine requirement the component model cannot meet, tested by asking a Salesforce developer who knows the platform rather than asserted in a design review, that is a real reason.

There is a fourth case that gets skipped, and it is the most common one. Twenty partners sending predictable requests to a mailbox two people manage comfortably do not need a portal. A shared inbox tool, a template set and a rule about what gets logged as a case gets most of the benefit for a fraction of the cost. The portal earns its place when the coordination cost is real: enough partners, enough repetition, and a visibility boundary that has to be enforced by something other than the judgement of whoever opens the mail.

#What we would tell you before starting

Settle the external access model before anyone opens the theme editor, and write down the negative test you would be most embarrassed to fail. On a dealer network that test is one competitor reaching another's orders, and it should be running from the first sprint.

Then be honest about adoption. A portal nobody logs into is almost never a design problem, and adding a news feed will not fix it. It is a task-completion problem: somebody arrived to finish a specific thing, could not, and went back to email, which still works. People return to a place that finished something for them. Everything else is decoration on a door nobody opens.