Customer Support Portal

This also controls what a contact sees in the AI widget's own requests list. Turn it off so a contact only ever sees their own requests, never requests from other people who share their company's email domain. You do not need the Scale plan to change this: the same toggle is available on the Feature requests settings page (Settings > Features > Feature requests) once your roadmap is public. See Publish your roadmap.

Who can see which requests

Request visibility in the Support Portal and the widget's requests list starts with company assignment, not with the individual contact. Productlane groups a contact into a company automatically based on the domain of their email address (Settings > Assignments > "Auto-assign contacts to companies by domain"). "Team requests" and "Cross-company thread visibility" both build on top of that company assignment:

• Team requests shows a contact every request tied to their company, including ones opened by teammates in that same company.

• Cross-company thread visibility only matters when a contact moves between companies. It controls whether they keep seeing threads from a company they used to belong to.

Shared email domains

Domain-based grouping assumes everyone on a domain belongs to one company. That breaks down when a domain is shared by unrelated people, for example separate teams at a large customer, or contacts using a shared vendor or personal domain. In that case Productlane still groups them into a single company, so with "Team requests" on, those unrelated contacts can see each other's requests, and each other's AI and widget conversations, since the requests list covers every channel a contact used (live chat, the widget's contact form, the Productlane Agent, email, and Slack).

To keep unrelated contacts on a shared domain from seeing each other's requests:

1. Go to Settings > Customers and split the affected contacts into separate company records, so they no longer share a company. This is the most precise fix, but you may need to repeat it whenever a new unrelated contact signs up on that domain.

2. If splitting companies is not practical, turn off "Team requests" on Settings > Features > Support Portal (or the matching toggle on Settings > Features > Feature requests). This is a workspace-wide setting: turning it off means every contact sees only the requests they personally raised, and no one sees their teammates' requests.

3. Set "Cross-company thread visibility" to Strict so that a contact who is later moved to a different company stops seeing threads from the company they left.

"Cross-company thread visibility" lives on the Support Portal settings page, so it requires the Scale plan. If you are on a lower plan, turning off "Team requests" is the way to isolate contacts who share a domain but are not actually related.

Linear issue status updates

When a thread is linked to a Linear issue, a status change such as moving to In Progress or Done in Linear appears as a timeline event on that request, both in the widget and in the Support Portal. A customer who opens the request sees its current status and the history of changes, without you writing an update by hand.

This is display only. It covers what is available today and what is not, so you can set the right expectation with customers:

• No proactive chat or email ping. Productlane shows the new status the next time the customer opens the widget or portal, it does not push a chat message or send an email the moment a linked issue's status changes. To message a customer proactively when their request ships, use Close-the-loop drafts, which prepares a draft for you to send when a linked issue or thread is marked completed.

• No context-aware duplicate suppression. Productlane does not track which status updates a customer has already been told about in conversation and skip repeating them.

• No goal-based conversation tracking. The Agent does not follow a customer's stated goal across a thread to decide when a status update is relevant to mention.

• No automatic updates across duplicate-linked issues. If a thread is linked to more than one Linear issue, status changes on each issue still only show up as timeline events, they are not summarized or pushed to the customer automatically.

These are logged as feature requests, not settings you can enable today. If a customer asks for proactive, context-aware status notifications, let them know it is on our radar rather than something misconfigured on their end.

Share a link to a specific conversation

When a customer asks for a link back to a conversation, send them the Support Portal, not the URL from your inbox.

• Your inbox URL only works for teammates signed into your Productlane workspace. A customer who opens it lands on a login screen, not the conversation.

• The Support Portal URL is customer-accessible. Once a customer opens it, every standalone conversation they've had with you, on live chat, email, Slack, the widget, or the Productlane Agent, shows up in their requests list, sorted with the most recently active conversation first.

The portal does not expose a separate URL per conversation. A customer reaches a specific thread by opening the shared portal link and picking it from their requests list, not from a link you copy out of that one thread.

Requirements to check before sharing

How to get the link

1. Go to Settings > Features > Support Portal.

2. Copy the public URL from the read-only field under "Make Support Portal public", or use your custom domain if one is set up.

3. Send that link to the customer. They land on their own requests list and open the relevant conversation from there.