n-Beacon Can Know Who's Asking Before They Say a Word. It Just Doesn't, Until Someone Tells It To.
Beacon is Help Scout's embeddable widget, a small piece of JavaScript that drops a contact form, a searchable knowledge base, and live chat onto your own site. Out of the box it's generic: the same widget for every visitor. Making it show the right account, plan, or order details for whoever's actually looking at it is a short integration, not a native feature.
What Beacon does on its own
Three tools in one widget. Beacon bundles a contact form, Docs search (Help Scout's knowledge base product), and live chat, and you choose which ones show and in what order. It installs with a JavaScript snippet on any site, or through the official WordPress plugin if that's your stack.
It's genuinely customizable, visually. Colors, text, which tabs appear, and where the widget sits on the page are all configurable from Help Scout's settings, no code required for the basics.
It doesn't know anything about the visitor by default. A logged-in customer and an anonymous visitor see the exact same widget. Beacon has no built-in way to pull in who's actually on the page.
Where identify and Secure Mode come in
Beacon ships a JavaScript API with an identify() call: pass it a visitor's name, email, and any custom attributes you want (plan tier, account ID, last order), and the widget carries that data into the conversation it creates. Nothing stops you from calling it, but nothing calls it for you either. Someone has to wire it into your own login or account system so it fires with the right data at the right moment.
Secure Mode goes a step further, verifying identity so a customer can see their own support history across devices without anyone spoofing their email to read someone else's conversations. It needs a signature generated server-side with a secret key from your Beacon settings, which means actual backend code, not a settings toggle.
What a wired-up Beacon looks like
The widget already knows the plan tier
A customer opens Beacon on your billing page and the conversation it starts already carries their account ID and plan, pulled from your own system the moment the page loaded, not typed in by the customer.
History follows the customer, not the device
Secure Mode set up correctly means a customer switching from their phone to a laptop still sees the same conversation thread, verified without exposing anyone else's history.
What does your login system already know that Beacon could be using?
Most of the data identify() needs is probably sitting in a session or account object you already have.
Running Beacon as the same generic widget for every visitor?
Tell us what you'd want it to know, plan tier, order status, account age, whatever actually helps an agent or shortcuts a question before it's asked. We'll wire the identify call and, if you need it, Secure Mode, into whatever system already holds that data. Beacon's one corner of Help Scout; we build this same kind of connection anywhere data's sitting still instead of showing up where it's needed.
Let's talk