Help Center

Docs

Everything you need to know about using Laureo

The Customer Ticket Portal

Give contacts a sign-in page where they can view and reply to their support tickets

What the Portal Is

A private ticket view for your customers, fed by the same Inbox your agents work.

The customer portal is a signed-in page where a contact sees their own support tickets: status, priority, your public replies, and attachments. They can reply from the portal, and replying to a resolved ticket reopens it automatically, so a customer is never stuck emailing a closed thread. Internal notes never appear in the portal, only the replies your team sends publicly.

A Business plan feature

The portal ships with the ticketing module on Business and above, alongside the other public support surfaces (your Help Center and live chat). Portal replies land on the ticket like any other customer message, so SLA clocks, assignment, and notifications all behave exactly as they do for email.

Inviting a Contact

Send a portal link from the contact's record.

Open the contact and find Customer portal

Go to People, open the contact, and switch to the Related tab. The Customer portal card sits with the contact’s tickets. You need the ticket edit permission to see it, and the contact needs an email address on file.

Send the invite

Click Invite to portal and confirm. The contact receives an email with a personal sign-in link that stays valid for 30 days. The link is theirs alone: it is never shown in the app, so it cannot leak from an agent’s screen.

Resend when needed

Resend link issues a fresh link and quietly retires the previous one, so there is only ever one live link per contact. Resends are briefly throttled to protect the customer’s mailbox from accidental double-sends.

Where the sign-in page lives

Your portal sign-in page sits at /portal/login/your-business, under the same public address as your Help Center pages and your website widgets. Only a workspace admin can change that address, and the addresses your workspace used before keep opening the sign-in page, so a customer who saved the link does not lose it in a rename. See Your Help Center Address.

A contact who already exists in your CRM can reach the portal without waiting for an invite. On the portal sign-in page they enter their email address and receive a 6-digit code that is valid for 5 minutes. Entering the code starts a normal 30-day portal session. The code is single-use and locks after a few wrong guesses, and the sign-in page answers the same way whether or not an address is recognized, so it cannot be used to probe which of your contacts exist.

One credential per contact

An invite and a code sign-in do not pile up separate live links. Signing in with a code refreshes the contact’s existing credential, and any visibility scope your team set is kept, so a routine sign-in never resets a support decision.

Company-Wide Visibility

Choose how much of their company's ticket history a contact can see.

By default a contact sees only their own tickets. For a champion or account admin at a customer company, you can widen that from the same Customer portal card once an invite exists, using the What they can see selector:

Own tickets: the default. The contact sees only tickets filed by or for them.
Company view: the contact also sees every ticket from their company, read-only. They can still reply on their own tickets.
Company view and reply: the same visibility, plus the ability to reply on colleagues’ tickets.

The scope belongs to the contact, not to a particular link: it survives resends and fresh code sign-ins until your team changes it. Company visibility follows the company on the contact’s CRM record, so keeping that association current is what keeps the portal view correct.

Revoking Access

Cut off a contact's portal access immediately.

Revoke access on the Customer portal card deletes the contact’s portal credential and invalidates any sign-in codes they requested but have not used. Every portal link they received stops working immediately. Revoking is the right move when a contact leaves the customer company or an inbox may be compromised. It is not a permanent ban: the contact can sign in again later with an email code, which starts them back at the default own-tickets scope.

Requests Awaiting Email Confirmation

Tickets filed by an unverified address are held until the sender confirms.

When someone files a request through your public Help Center form, they may type any email address. Until that address is confirmed, the ticket is created in a pending verification state: the sender gets a confirmation email with a link that is valid for 7 days, and clicking it marks the request as genuine.

What pending means in practice

A pending ticket does not start your SLA clocks and does not notify your team, so nobody is paged for a request that may never be real. In the portal, a pending ticket is visible only to the contact who filed it. It never appears in a colleague’s company-wide view, so no one can surface someone else’s ticket just by claiming their address. Once the sender confirms, the ticket warms up: SLA targets arm and your team is notified as usual.