Skip to content
Solution Blueprint

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-header-icon

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-header-icon

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-header-icon

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-header-icon

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-header-icon

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-header-icon

Impact

check-icon

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.

check-icon

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.

check-icon

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.

check-icon

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.

Technical Blueprint
1

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.

2

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.

3

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.

4

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.

One FAQ source feeding three HubSpot Knowledge Base instances: public, login-gated, and in a partner's branding.

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

Why build three separate knowledge bases instead of one with filtered views?

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.

How did the partner-branded instance stay consistent with the other two?

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.

Continue reading

209049052787

Australian online pharmacy: Service Hub audited for medical data

209049052787

Clinical IT provider: custom data room saves $120k a year

209049052787

Australian meal-delivery charity: HubDB calculator prices by funding type

209049052787

National aged care provider: shared-email contacts via association labels

209049082794

National childcare provider: Family Support tickets routed in Service Hub

209049052787

Medical device maker: automated clinical triage in HubSpot

footerCTA footerCTA-mobile
Spice up your inbox
Sign up for our newsletter
Don't worry - we only average, like, two emojis per subject line.