Portals6 min readBy the Kiwi senior team

Customer success portals: jobs, not a public status page

A success portal earns its login when clients can finish a job: see current work, upload evidence, or approve a milestone. A public status page is a different product.

In this guide
  1. Direct answer
  2. Jobs that justify a login
  3. A practical sequence
  4. Mistakes that look like progress
  5. What to send if you want a senior review
  6. Questions
  7. Sources

Direct answer

If the only job is ‘see if we are down’, ship a public status page. If the jobs are ‘see my work, upload a file, approve a step’, you need an authenticated success portal with access control.

Do not hide a status page behind a login. Do not index a success portal in the marketing sitemap.

Jobs that justify a login

Useful jobs: current milestone, open questions, file exchange, invoice or PO status if you already handle money elsewhere, named owner. Useless jobs: a vanity NPS widget, a blog mirror, a second copy of the public site.

Every job needs an empty state and a next action. Usability 101: the user should know what to do without a training call.

A practical sequence

Start with one workspace and one client-facing role.

  • Write the three jobs in the client’s words
  • Map each job to one object and one permission
  • Label every field; never use placeholder-as-label
  • Notify through an outbox, not a silent failure
  • Keep the public website for buyers who are not yet clients

Mistakes that look like progress

Avoid these:

  • Cloning Intercom and calling it a portal
  • Giving every client the same demo tenant
  • Measuring ‘logins’ instead of jobs completed

What to send if you want a senior review

Share the jobs a client cannot finish in email today. Related work at Kiwi: SaaS MVP design and development. Walkthroughs available on request.

Frequently asked questions

Can the portal live on a subdomain?

Yes, if cookies, CORS, and robots are explicit. Subdomains are not automatically safer. Access control still has to run on every request.

Should support chat live inside the portal?

Only if you will staff it. A mailto or a ticket object is enough for v1. Chat widgets on a marketing site are a different consent and load problem.

How do we prove the portal works?

Complete the three jobs in a walkthrough. Do not publish unnamed ‘time saved’ claims.

Sources

Figures cited above are drawn from the linked publications and are the responsibility of their sources; we date and scope them rather than presenting them as universal guarantees.

What would this change for your business?

Share your goal and the challenge behind it. We’ll help you turn the useful ideas into a practical first step. A senior practitioner replies within one business day.

Start a project