Case study
Whitelabeling ThoughtSpot’s emails
A case study of exploring the problem and finalising on the solution.
ThoughtSpot’s embedded customers put our products — dashboards, charts, sometimes the whole ThoughtSpot app — inside their own products. Their end users never see the word “ThoughtSpot,” since everything they interact with is whitelabelled and consistent with our customers’ branding — until an automated email shows up. Alerts, scheduled reports, and anomaly notifications from these whitelabelled products all went out with our logo, our vocabulary, our branding, from inside a product that was our customer’s. To their end users, it looked like a stranger had gotten into their inbox.
This was a big blocker for rolling out the Communications platform to the entire set of embedded customers — roughly 75% of our customer base. On top of that, $5M of open ACV was sitting behind customers asking us to fix it.
Exploring the problem — and the real job to be done
Customers’ first ask was blunt: stop sending the emails entirely. Their end users were confused to see ThoughtSpot notifications appear out of nowhere, and given what they were dealing with, that ask was a reasonable one.
Further conversations surfaced a different picture. The email itself wasn’t the problem — it was doing real work, carrying alerts and dashboard PDFs that brought people back into the product. The problem was that the email carried ThoughtSpot’s branding: a name their end users had never heard of, because they didn’t know ThoughtSpot was running underneath their product in the first place. It wasn’t the email that felt like a stranger in the inbox — it was the name on it.
So the job to be done wasn’t “stop sending emails on our behalf.” It was “make this email look like it came from us, consistent with everything else we send.” Customers didn’t need to own the email — they needed to own the identity on it.
Solution exploration
Working with design, I mapped out four options that sat on the table, ranging from what customers asked for first to a full rebuild of how emails work.
Block all emails
Customers' first ask
Enabled
No more emails carrying ThoughtSpot's branding.
Didn’t enable
No emails at all — customers lose alerts on threshold breaches, scheduled reports, and anomaly notifications entirely.
Full email editor
The way Okta does it
Enabled
Complete control over the email — layout, content, even the data, populated through placeholder variables customers could place anywhere in their layout. ThoughtSpot still owns the logic to send it, so the data itself is never manipulated.
Didn’t enable
Customers would still decide which data went where — a mismatched placeholder becomes a trust problem for us, even if it's their mistake. It's also not worth the investment: notifications aren't a product ThoughtSpot sells, and it would have held 75% of the customer base at a standstill until something close to perfect shipped.
Webhooks
Hand customers the data, let them build their own workflow
Enabled
Already on the roadmap as an “if this, then that” flow across events. Customers get the data and decide how to react — including an email whose layout, structure, content, and data are entirely theirs.
Didn’t enable
Real flexibility, but real effort: customers have to listen for the event, write the logic to react to it, and build and maintain the whole workflow. Most won't have the resources or bandwidth to take that on.
Fixed template, configurable identity
ChosenWhat we chose
Enabled
Customers own their identity — logo, colors, footer, vocabulary — so the email looks like it came from them, and control the visibility of every non-data component. ThoughtSpot keeps control of the structure, so data from our logical pipelines is always shown correctly.
Didn’t enable
Not complete control: customers can't rearrange layout or add, remove, or reorder structural sections. They also can't control the logic of sending the email itself — for that, they'd need webhooks.
The decision
The same scale I’d flagged earlier — 75% of our customer base — set the bar for the fix: it had to work for the mass with little friction to adopt, and it had to ship soon enough to unblock customers rather than make them wait for a perfect answer.
Weighed against that bar, whitelabeling the email — the same treatment we already give the rest of the product — was the clearest way to deliver the job to be done: make the email look like it came from the customer, without asking them to build one from scratch. It’s why the fixed template won out over the editor and webhooks: it met the identity ask directly, at a cost we could ship fast and customers could adopt without friction.
Testing the thought process
Before building anything, I went back to a set of customers who’d shown interest in this problem from the start, to walk them through our thinking and the solution we had in mind. All but one agreed it would solve their problem. The one exception had a specific need only webhooks could meet — they wanted control over the logic of sending the email, not just its identity.
Beta showed the same pattern. Every customer who signed up applied the customization without fail — the trade-offs we made held up.
For that remaining slice of customers who need real control over sending logic, we’re building webhooks separately — early, and intentionally scoped smaller, because it’s solving for the exception, not the rule.
What shipped
Self-served customization of the emails — logo and color palette customization, a content system that lets customers swap our terminology for their own (Liveboard, Answer, SpotIQ, ThoughtSpot), and visibility toggles for anything ThoughtSpot-specific in the email body — the mobile app nudge, alert and unsubscribe links, support and privacy links.
Settings apply at the org level, with per-org overrides on top of cluster-wide defaults, so a customer running multiple embedded orgs isn’t stuck with one brand across all of them — each org can have its own customization.
Delivered as APIs first, UI second — sequenced that way because our primary customers here are embedded engineering teams comfortable working against an API directly. You can see the shipped result in ThoughtSpot’s own documentation →.
The outcome
It unblocked the customers who’d pushed for it the most, back during the beta phase itself. Now that it’s GA, it’s helped roll out the Communications platform fleet-wide — what was our long-time goal.
What I’d revisit
The API-first sequencing made sense for the persona I had in mind, but I’d build the UI alongside the API if I did this again. Sequencing them one after the other meant the full solution took longer to ship than I’d planned for — building them together would have gotten the complete experience out sooner. It also would have helped adoption: even customers who are comfortable with an API adopt faster, and need less explaining, when there’s a UI in front of it. I underweighted how much a UI reduces the cost of teaching a feature, even to a technical audience.
Key takeaway
Customers’ first ask is rarely the real job to be done — “stop sending the emails” was really “make this email look like it came from us.” The best solution wasn’t the one with the most control, or the cheapest to build; it was the one that matched the actual job at the scale and speed the problem demanded.