Knowledge Base Instances Split by Domain, Login, and Partner Brand
A native Knowledge Base instance ties to one domain, so a reverse brief naming three separate domains meant three separate builds, not one shared instance with a filter on top. The brief split an on-demand pharmacy's self-service content by audience: a public FAQ for retail customers, a login-gated library for internal support staff, and an instance built to a referral partner's own branding for customers arriving through that partnership.
Executive Summary
Context
An Australian on-demand pharmacy and medicine delivery service needed self-service content for three audiences who should not see the same thing. Customers asked about orders and scripts, staff needed detail no customer should read, and customers referred through a health-insurance partnership expected that partner's own look. One Service Hub feature, configured three times, served all three from one set of client-supplied FAQ material.
What We Built
We built three separate HubSpot Knowledge Base instances from one reverse brief: an open FAQ for retail customers, a gated instance for internal staff, and a partner-branded instance designed in Figma. Each drew its categories from the same client-supplied FAQ material.
Tech Stack
- HubSpot Service Hub
- Figma
Not a fit if one public FAQ already serves every audience a business has, since separate instances only pay off once audiences need different content, access, or a look. It's also not a fit without one existing FAQ set ready to split, since the three taxonomies depend on that material existing before any instance is built.
The Challenge
Three audiences needed three different experiences from what HubSpot ships as one Knowledge Base feature. Retail customers needed a public instance that answered ordering, delivery, script, and medication questions, with no internal detail beside it. Staff needed a second instance carrying operating detail that no customer should see, so it couldn't sit on the public domain.
Customers referred through a health-insurance partnership needed a third instance that read as the partner's own product, not the pharmacy's support page under someone else's name. A native instance binds to one domain, so three domains meant three instances. Each one still had to draw from the same underlying FAQ material, rather than from three independently written sets.
Our Approach
The reverse brief set the domain, audience, and category structure for each instance before any build started. We planned one open customer domain, one internal domain behind a login, and one partner domain matching the referral partner's own colour scheme. We gated the staff instance with an email and password login so that operating detail stayed off the public instance entirely.
We designed the partner instance in Figma to the partner's branding rather than the pharmacy's, so that a referred customer would recognise the partner and not a third-party tool. All three instances categorised the same source material, covering ordering, delivery, scripts, and medications, differently for each audience. We chose that over duplicating one taxonomy three times.
Impact
a public FAQ instance carrying only customer-facing content
Retail customers reached one instance built solely around ordering, delivery, script, and medication questions, with no staff process detail or partner branding anywhere near it, keeping the public domain focused on what a customer actually asked.
an internal instance staff could use without exposing process detail publicly
Support staff got a second instance behind an email and password login, so operating detail that never belonged on a public page had somewhere to live.
a partner-branded instance that reads as the partner's, not the pharmacy's
Customers referred through a health-insurance partnership reached an instance designed to that partner's own branding, supporting the referral relationship without turning the partner's customers into visitors on an unfamiliar third-party support page.
three instances from one FAQ source, not three separately written ones
Every instance drew its categories from the same client-supplied FAQ material, so building three audiences' worth of content meant re-categorising one source three ways rather than commissioning three unrelated content sets.
The customer-facing instance used its own public domain, scoped to ordering, delivery, script, and medication questions pulled from the client-supplied FAQ material, with no internal or partner content anywhere on it.
The staff-facing instance required an email and password login before any page loaded, the mechanism that let it carry operating detail the public instance could not, without that detail becoming visible outside the support team.
The third instance was designed in Figma to a referral partner's own colour scheme and identity rather than the pharmacy's, so customers arriving through that partnership saw the partner's branding, not a generic knowledge base.
Each instance organised the same underlying client-supplied FAQ material, covering ordering, delivery, scripts, and specific medications, into its own category structure suited to its audience rather than reusing one taxonomy across all three.
A native Knowledge Base instance binds to one domain, so three audiences meant three instances. Each still had to draw on the same FAQ material, not three separate sets. The staff instance now sits behind an email and password login, so operating detail stays off the public domain. The partner instance is designed in Figma to the referral partner's colour scheme. All three categorise one client-supplied source differently for each audience.
FAQ
A native Knowledge Base instance binds to one domain. Three audiences needed three different domains: an open one for customers, a login-gated one for staff, and a partner-branded one for referred customers. So three domains meant three instances, rather than one instance with a filter layered on top.
All three instances drew their categories from the same client-supplied FAQ material covering ordering, delivery, scripts, and medications. Only the domain, the access gate, and the Figma-designed branding changed between them, so the underlying content stayed one consistent source even as its presentation differed by audience.
