Customer portal — branded self-service for tickets, tasks, forms

What the customer portal does

The customer portal is a branded, self-service web destination for your customer — separate from your internal workspace. Each customer gets a login at your subdomain (e.g. portal.youragency.com). When they log in, they see:

• Open tickets — status, threads, replies, attachments
• Active onboarding — what's in progress, what's next, what's due from them
• Forms to complete — anything you've assigned to their tasks
• Documents — your shared artifacts (contracts, deliverables) and their uploads
• Recent activity — chronological timeline of what's happened with their account

What they don't see: internal notes, your team's chat, your other customers, the back-of-house workflow.

How portal access works

Portal users are a distinct role tier:

• Portal user — sees only their own company's data; no internal layer at all
• Authenticated via email + password (or magic link)
• Per-customer scoping — Acme's portal user only sees Acme data
• Multiple contacts per customer can have portal access

The data model enforces this at the query layer. There's no way a portal user accidentally sees another customer's information — the ownership check runs on every request.

What customers can do from the portal

The portal_tickets route surface (a ~24KB route file in the backend, the largest of any portal-specific endpoint) gives portal users:

• Submit a new ticket — same Ticket model your team sees, just scoped to their own customer
• Reply to open threads — replies append to the same email_thread_id
• Watch status changes — SLA timers, assignment, resolution all visible
• See linked tasks — if a ticket spawned an onboarding task, the customer sees that too

For onboarding tasks specifically, the CustomerTask model carries a parallel "portal" set of fields — portal_status, portal_start, portal_complete, portal_assignee — that let you control what the customer sees independent of your internal state. The customer might see "in progress" while your team sees "blocked on legal review" — useful framing without misleading.

Branding

Portals are fully white-labeled on every paid plan:

• Custom subdomain (CNAME to your domain)
• Logo upload (light + dark variants)
• Primary color picker
• Custom favicon
• Optional custom CSS for Enterprise plans

Once configured, the portal looks like your product. Customers don't see "BlueHill" — they see your brand.

Forms in the portal

The portal is where the Forms feature really earns its keep. Onboarding steps that require structured data from the customer (account details, brand assets, IdP metadata) get a form attached. The customer logs into the portal, completes the form, and the task auto-progresses. The data lands on the customer record.

Result: fewer email back-and-forths, faster onboarding, cleaner data capture.

Document handling

Each customer record has a document store. The portal exposes the customer's own uploads (their tax forms, their brand assets, their MSAs) plus any shared deliverables your team has published. Files are stored encrypted at rest, with download URLs scoped to authenticated portal sessions.

Mobile

The portal is responsive — about half of portal logins in production happen on mobile, especially in the morning before the customer is at their desk. The core flows (submit ticket, view status, complete form) all work at 375px width.

What this replaces

Teams arriving at BlueHill for the portal feature are usually moving off:

• Third-party portal vendors that bolt onto a help desk (extra subscription, no real branding)
• Notion or Google Sites pages shared publicly (no auth, no scoping, no real-time data)
• Email-only collaboration (no shared state, lots of "what's the status?" pings)

Built for

• Agencies giving each client a self-service workspace
• Professional services firms collaborating with multiple stakeholders per engagement
• Customer success teams wanting customers to self-serve status checks

Try it

Start a 14-day free trial — no credit card required.