Portals people actually finish tasks on

Somebody arrives at a portal because something else has already failed. They looked on the public site and did not find it. They rang and heard the queue length. They sent an email four days ago. Almost nobody opens a customer portal out of interest, and the ones who do are not the ones the business case was written about.

That framing changes what the thing is. A website is browsed, and an eleven minute session on a website is a good one. A portal is where a person goes to finish a specific task, and an eleven minute session there is usually somebody who could not find the button. The two get built by the same teams, measured with the same tools and reviewed in the same meeting, which is how a portal ends up optimised for the behaviour it should be eliminating.

Take task completion as the only metric that matters and most of the standard decisions look different. Several of the ones taken earliest look wrong.

#The top tasks are not the ones from the workshop

Ask the organisation what the portal should do and you get an answer shaped by the organisational chart. Every department that has heard about the project wants a presence in it. What comes back is a navigation mirroring internal structure, a resource library, a news feed, a community area, and a personalised dashboard nobody has been able to describe the contents of.

The real list is already sitting in the service data. Take twelve months of cases grouped by reason, the call drivers from the telephony platform, the subject lines of inbound email, and the site search terms from the public website. Group them by the task the person was trying to finish rather than by the department that handled it, and rank by volume. If the case taxonomy will not support that grouping, that is the first finding, and it is a bigger one than the portal: a case model you can still report on in three years is the prerequisite for knowing what your customers contact you about at all.

The result is reliably uncomfortable. Three or four tasks account for the bulk of contact, and they are dull: where is my thing, send me a copy of that document, what is happening with the request I raised, change this detail on my account. None of them were what the sponsor wanted to fund. The community area and the curated content hub, which had names and owners and slides, sit somewhere below in the volumes, often far below.

#Traffic and page views measure the wrong thing here

Portal reporting defaults to the metrics a marketing site uses, and on a portal most of them point the wrong way.

Page views rise when people cannot find things. Session duration rises with confusion. Portal visits rise when the phone queue is long, which means the traffic line goes up on exactly the weeks service is worst. Registered users accumulate and never decrease, so the number always looks like growth even when the same few thousand people are the only ones who ever return. Bounce rate is close to meaningless here: somebody who landed, read the one line they needed and left has bounced, and that was a complete success.

There is one reading of page views worth keeping, and it is inverted. Pages per completed task, tracked per task, should be low and should be falling. A customer who touched two pages to get their invoice had a better experience than one who touched seven, and no other traffic metric distinguishes between them.

The uncomfortable version of this is that a portal doing its job produces a flat or falling engagement chart. Fewer pages, shorter sessions, fewer repeat visits per task. Any programme reporting engagement growth as evidence of portal success should be asked which of those numbers it would be happy to see fall.

#Login is where most of the abandonment happens

Registration and authentication sit in front of every task on the list, which makes them the largest single point of loss in most portals, and the one least likely to appear in a design review because it is treated as plumbing.

The failures are specific and repetitive. The customer cannot remember which email address the account was created under. The activation message went to spam, or arrived eleven minutes later than their patience. A contact record already exists with a different address, so self registration creates a second identity and the history the customer expects to see is attached to the first. Verification asks for an account number printed on a document they do not have in front of them, which is frequently the document they came to download.

Three things help, in order of how much.

Decide per task whether identity is genuinely required. Order status against a reference and a postcode does not need an account. A published answer to a common question certainly does not, and putting knowledge behind a login is the most common self inflicted wound in this category: it removes the deflection the content was built for, and it removes the content from search results at the same time. Salesforce is explicit that a customer portal mixes public and authenticated experiences, so the mix is a design decision rather than a platform constraint.

Authenticate at the point of value. Let somebody reach the answer, the status or the form, and ask for identity at the step that actually needs it. A login wall at the door asks people to pay a cost before they know whether the thing they want is even in there.

Instrument it. Registration starts against registration completions. Password resets as a share of login attempts. Contacts who hold a portal account and have never completed a task on it. The gap between account creation and first completed task, which when it is long tells you people registered under pressure and then abandoned the thing they registered for.

#Started but did not finish

Ask a portal how many requests were raised last month and it will answer. Ask how many people opened the request form and left without submitting and most portals cannot answer at all, because nothing was recorded when the person started.

That second number is the one worth having. Completions tell you the size of the success. Starts against completions tell you where the design is failing and roughly why.

Producing it takes a small amount of deliberate work per task. Define each top task as an ordered sequence of steps. Define an entry event, fired when the person commits to the task rather than when they land on the page, and a completion event tied to the record that proves it happened: the case created, the document downloaded, the appointment booked, the detail changed. The completion side usually exists already, because the completion is a record in Service Cloud. The entry side almost never exists, and it has to be created on purpose.

What comes back is a per task abandonment profile, and the step where people leave usually names its own cause. A mandatory field only the back office knows the answer to. A reference number the customer does not hold. An attachment step that rejects a photo taken on a phone and returns an error written for an administrator. A payment handoff that opens in a new context and loses the reference. A confirmation screen saying the request has been received without saying what happens next, which produces the phone call the whole exercise was meant to prevent.

The secondary benefit is political. Once starts and completions exist per task, arguments about what users want get settled with a number instead of a louder opinion, and the roadmap stops being a queue of departmental requests. The broader build discipline behind all of this sits in Experience Cloud projects fail on the sharing model, not the theme.

#Content that answers rather than describes

Most portal content arrives from the website, and website content describes. It explains what a service is, states what the organisation is committed to, and sets out a policy in the order the policy was written.

Somebody halfway through a task needs the answer in the first two lines, in the words they used when they searched. The rewrite is close to mechanical once that is accepted.

Title the article as the question, using the customer vocabulary that appeared in the search terms and case subjects rather than the internal product name. Put the answer in the opening sentence and the qualifications underneath it. Write one article per question rather than one per policy document, because a customer with one question will not read eleven paragraphs to find the two lines that apply to them. 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 it in place. Knowledge reachable only through a search box is knowledge most people will not reach, and matching articles to the task somebody is already performing does more for completion than any amount of work on the search algorithm. Salesforce covers the capability side of customer self service portals well enough, and capability has not been the constraint on this for years.

#The task completion audit

This is the table we build in the first week of a portal review. One row per task from the ranking, the step where people leave, and the cause we would test first. The third column is a hypothesis rather than a finding, and every row is checkable inside a day.

Two rows are worth pointing at. The last is not an abandonment at all, it is a task that never began, and it is invisible in every portal metric because the person was never there to be counted. The address change row shows the shape of the most expensive failure available: the task completed, and the contact happened anyway.

#Did contacts fall, or did they just move

The honest test of a portal is whether contact about the tasks it handles went down.

That is a narrower question than the one usually asked. Total call volume moves for reasons that have nothing to do with the portal, so compare the specific call drivers and case reasons for the tasks the portal now handles, over comparable periods, against what was happening before. A portal that completed forty thousand tasks and reduced calls by four hundred did not deflect forty thousand contacts. It gave people a cheap way to check things they would never have phoned about, which is a genuine improvement in service and is not a saving, and it should not be presented as one.

The measurement that catches the expensive case is contact within a day or two of a portal session, grouped by task. Those are the people who used the portal, did not get what they needed, and rang anyway. They cost more than the customers who simply phoned, because the organisation paid for both channels and the customer paid twice in patience. Rising portal usage alongside flat contact volume is the signature of exactly that, and it is usually presented as adoption. The same discipline applies to automated answers layered on top of the portal, which we set out in deflection that does not cost you the customer.

#Where to start on a portal you already have

Take the four tasks at the top of the contact ranking and ignore everything else for a quarter.

Instrument entry and completion for those four, so you know the current completion rate before anything changes. Fix login for those four specifically, starting with whether each genuinely needs an account. Rewrite the content behind them so it answers rather than describes. Then read the abandonment profile again and fix whatever the largest remaining step is.

What that deliberately postpones is a navigation redesign, which is where portal programmes usually begin. Navigation is the visible part and the part everyone has an opinion about, and it is rarely where people are lost. They are lost at a login they cannot get through, a field they cannot answer, and a page that describes something instead of telling them the thing.

The question worth asking about a portal is not how to increase adoption. It is which task somebody was trying to finish, where they stopped, and what was in front of them at that step.