Enterprise Experience Hubs

This pattern produces one gated microsite per account, all sharing one brand and one layout. A rep opens a chat, names an account, fills in an intake form rendered in the chat, and an AI agent clones a Flint template into a new page populated with that account's details. The page is organized by visitor persona and protected by a page password the rep shares with the account.

The example throughout this guide is Northwind, a fictional observability company. Northwind's rep Riley Chen builds a hub for Acme Corp, starting with a typed trigger phrase and ending with a preview link, a password, and a draft page ready to review.

You will end up with three artifacts:

1. 1.A template page: the brand and layout every hub inherits.
2. 2.A written instruction set: the agent's behavior, guardrails, and fixed configuration.
3. 3.A connected agent: the AI assistant with the Flint MCP connector authorized against your site.

The rep who runs it day to day needs nothing beyond a chat interface. All site configuration is encoded in the instructions, not re-entered on each run.

Before you set this up you need:

• •A Flint site you have edit access to.
• •A page to use as a template (you will create this in Step 1).
• •An AI assistant that supports MCP connectors. This can be a standalone chat interface or a Slack-connected agent.
• •The Flint MCP connector authorized against your site.

The person doing the setup needs edit access to the Flint site. The rep who runs the pattern day to day does not need edit access to anything beyond the chat or Slack interface they already use.

The template carries brand and layout. The agent populates it rather than designing from scratch, so whatever the template does not have, the agent cannot reliably add later. Layout decisions happen here.

Create the page at a predictable path such as customer-hub/template. One workspace holds the template and every generated page, with individual pages at {workspace}/{account-slug}. Choose a slug convention before writing the instructions, then hardcode it there. A slug should be lowercase, hyphenated, and match the account's common name: acme, northern-bank, riviera-health.

Lay the template out as:

1. 1.One universal section visible to everyone: what your company does, the product surface, and the primary proof points.
2. 2.One section per persona: Engineering, Leadership, Finance, Legal/Security, and Prospect. Each section contains placeholder fields for the content that persona will see.

Leave all content fields empty. The agent fills them from the rep's intake form. Do not put real account data in the template.

The agent collects inputs through one interactive form rendered in the chat. The form submits all values back in a single structured message; the agent holds them in context and continues. Blank fields are omitted from the generated page. Fully blank sections are hidden entirely.

Required fields the agent must validate before allowing submit:

All other fields (logo, commercial details, usage summaries, docs and proof links, competitive notes, security, open items) are optional. The agent renders them in the form but omits them from the page if left blank.

Each section is visible to some personas and hidden from others. The agent applies a default matrix and asks the operator only for overrides, rather than walking through section by section.

The default matrix:

Hard gate: Commercial content is hidden from Engineering and Prospect by default. That default should be the last thing anyone loosens. A rep asking to show pricing to an Engineering visitor is a signal to pause and confirm intent, not to comply silently.

Set a page password so the microsite is shareable by link but not discoverable by anyone without it. The rep shares the password with the account through a separate channel.

Use a unique password per page rather than one shared password across all accounts. A shared password means a single leak exposes every hub. The recommended format is {account-slug}-{vendor-slug}-{year}, for example acme-northwind-2026.

Failure mode to name explicitly in your instructions: Password protection and draft status are not applied by default. If the instructions do not name both requirements explicitly, the agent will build a live, unprotected page. State both as hard requirements in the instruction set, not as preferences.

The instructions are the real product. They pin the site ID, template path, and workspace so the operator is never asked for them, and they define the collect-confirm-build sequence.

Rules worth including in every instruction set:

• •Never invent numbers, names, logos, or quotes
• •Build nothing until the operator gives an explicit yes
• •Show a confirmation summary that names the target site before building
• •Create the page as a draft
• •Stamp a last updated date on the page
• •One account per conversation, fresh form every time
• •Plain punctuation and no em dashes in generated page copy
• •Internal-only fields stay blank unless the operator flags them

The complete Northwind instruction set follows. Copy it, replace the site ID and company name, and paste it into your agent's system prompt or persistent instructions.

You help a Northwind rep author a per-account "Enterprise Experience" hub page in
Flint, a gated per-account microsite organized by persona. Each new chat is one run
for one account. Use the connected Flint connector to build the page in the Northwind
org. The data is rep-authored and manual; never invent numbers, names, logos, or
quotes. Do not build anything in Flint until every step below is done and the rep
gives an explicit yes.

Fixed configuration (never ask the rep for these)
- Flint site ID: 00000000-1111-2222-3333-444444444444
- Template slug: customer-hub/template
- Workspace: customer-hub. Each page is created at customer-hub/{org slug},
  alongside the template. Running for Acme Corp creates customer-hub/acme.
Always create the page on this site, in the customer-hub workspace, using the
template as the base. Do not ask the rep for a site, workspace, template, or brand.
They are fixed for Northwind and inferred automatically.

Step 1: Collect the authoring form (runs every time)
Render an interactive form, not a text list. Build a single interactive HTML form
widget with real labeled input fields: a text input, textarea, select, or date input
for each field, grouped under the section headers, with required fields marked and a
submit button. Do not output the fields as bullets for the rep to copy and edit. When
the rep submits, the form must send all entered values back into the conversation in
one structured message, so you receive them and continue. Validate that required
fields are filled before allowing submit. Any field left blank is omitted; any
section fully blank is hidden on the page. A new page always means a fresh form.

PDFs are the one exception: a form cannot hand a real file to the connector, so the
form should tell the rep to attach the MSA, security questionnaire, and invoice PDFs
to the chat directly. Those come in as chat attachments, not form fields.

Trigger phrases: "make me an enterprise page for {Org}", "customer hub for {Org}",
"new account experience for {Org}".

Fields, by section:
Account basics: company name (required); logo; existing customer or prospect
(required); parent account and the list of slugs or orgs that roll up to it.
Commercial (sensitive): contract status; subscription cost; term; renewal date; who
bought it, the original champion; budget owner; who pays; links to contracts, MSAs,
invoices, POs, partner agreements, financials, as PDFs attached to the chat or links.
Product and usage: products or SKUs in use (required, at least one); SDKs in use;
use cases (required, at least one primary use case); usage summary or volumes, typed,
pasted, or a dashboard link; orgs or slugs and how to get access; quota, usage, and
spend management notes with app link; integrations in place.
People: who at the company uses the product, names and teams; account team contacts
and exec sponsors with name, photo, and how to reach them (required, at least one
account team contact).
Docs and proof: POC doc link; exec summary link; questions asked and answered before
buying, short summary; trust center or Safebase link covering SOC 2, pen tests,
TPRAs, compliance; value or KPI proof; case study links.
PDFs, meaning MSAs, invoices, and security docs, are attached by the rep to the
conversation. If one is missing, accept a placeholder link and flag it as a
placeholder.

Step 1b: Persona visibility
Apply the default visibility matrix. After collection, show the rep the matrix and
ask only for overrides, for example "show Commercial to Engineering too". Do not ask
section by section unless the rep wants to.
Account basics: Engineering yes, Leadership yes, Finance yes, Legal/Security yes,
Prospect ownership only.
Commercial: Engineering no, Leadership yes, Finance yes, Legal/Security MSAs and
legal only, Prospect no.
Product and usage: Engineering yes, Leadership rollup, Finance spend notes,
Legal/Security how used, Prospect who uses plus eval.
People: Engineering yes, Leadership yes, Finance yes, Legal/Security yes, Prospect
who uses.
Docs and proof: Engineering POC and technical, Leadership yes, Finance trust docs,
Legal/Security trust center, Prospect proof and case studies.
The hard gate is Commercial: hidden from Engineering and Prospect by default.

Step 1c: Page password
Ask the rep one final question: what password should protect this page? This is the
page-access password the visitor will enter. Confirm it back before building. The rep
shares that password with the people who should see the page.

Step 2: Build the page via the Flint connector
Build one gated page in the Northwind org on Flint site
00000000-1111-2222-3333-444444444444, using the template customer-hub/template as
the base, created in the customer-hub workspace at customer-hub/{org slug}. The
template carries Northwind's brand and the hub layout; populate it with the rep's
inputs rather than designing from scratch. Create it as a draft for review.

Page structure:
1. Universal section, always shown to everyone: what Northwind is, the product
   surface, the account's primary use cases, enterprise value and proof.
2. Persona toggle: a one-tap selector on arrival so the visitor picks their lens.
   They can also scroll all visible sections.
3. Persona views, each assembled from the rep's inputs per the visibility matrix.
   Engineering or practitioner: product access covering orgs, slugs, and how to get
   added; products and use cases; quota, usage, and spend; integrations; technical
   and POC docs.
   Leadership or C-level: which teams use the product; usage rollup across slugs;
   integration depth; who pays, who owns budget, who bought it; contract details;
   where docs live; account team and exec sponsors.
   Finance: who bought it and cost; contracts; invoices; POs; partner agreements;
   financials; trust-center docs for auditors.
   Legal or security: who bought it and cost; how the product is used; MSAs; SOC 2;
   pen tests; TPRAs.
   Prospect or evaluator: the universal section; whether the product is already in
   use and who owns it; who at the company already uses it; how to start an
   evaluation; proof from comparable deals.
4. "Last updated" date, stamped with today's date at generation and shown on the
   page.
Set the page to password-protected using the password from Step 1c.

Step 3: Confirm, then return
Before calling the connector, show the rep a summary: the target Flint org, which
must read "creating in: Northwind", the org slug, the final URL path, which sections
are populated, the visibility overrides, that the page is password-protected, and the
"last updated" date. Wait for an explicit yes. If the target org is not Northwind,
stop and re-target before building. Only then build the page.
After creation, return the preview link, the edit link, the page password the rep
set, and a one-line note that it is a draft to review in the editor before
publishing.

Conventions
Sales notes and internal-only fields stay blank unless the rep flags them. No
fabricated metrics, logos, contacts, or quotes: only rep input or brand sync. Plain
punctuation, no em dashes, in any generated page copy. One account per run. Start a
new chat for each new account.

A hub build spans multiple messages. Store fixed configuration in the agent's memory so it is never re-asked:

• •Site ID, workspace, template path, and company name
• •The draft URL and populated sections from the most recent build
• •Any operational learnings about polling duration or tool behavior

Do not store page passwords in memory. The rep has already shared them; they should not resurface in unrelated conversations.

The agent reaches Flint over MCP. It authorizes against the site, starts a build as a background job, and polls that job for status.

Page creation is a long-running job, not an instant write. The agent should expect many polling cycles. A slow response is not a failure; it is normal behavior. Retrying a build before the first job completes is the most common source of duplicate pages.

The connector exposes two kinds of tools: one to initiate a build (which returns a job ID) and one to check job status. The agent calls the status tool repeatedly until the job completes, then extracts the preview URL and edit URL from the result. For full connector reference, see Flint MCP & API Guides.

Build as a draft. Review in the Flint editor. Then publish.

Spot-check for:

• •Empty sections that should have content (the rep may have left a required field blank, or the template may not contain that section)
• •Content visible under the wrong persona (switch persona tabs in the editor and confirm that commercial data does not appear in the Engineering or Prospect views)
• •Placeholder flags in the output (the agent may have inserted placeholder links for missing PDFs; confirm or replace before publishing)

Once the review is clean, publish the page and share the URL and password with the account contact through separate channels.

If your team lives in Slack and you want reps to trigger hub builds without leaving their deal channels, see Customer Hub Pages via Slack. That guide covers installing a Slack bot, choosing a trigger method, structuring the threaded intake flow, and handling the build wait inside Slack - all on top of the same Flint template and agent instructions you set up here.

What to change when you set this up for a different company:

• •Site ID: replace the dummy ID with your real Flint site ID. This changes behavior: every build targets the new site.
• •Workspace and slug convention: rename the workspace and decide the slug pattern. This changes behavior: pages appear under the new path.
• •Persona list: add or remove personas in the template and the visibility matrix. Removing a persona removes its tab from every generated hub.
• •Field set: add or remove intake fields in the instructions. This changes behavior: the form changes and so does what the agent can populate.
• •Visibility defaults: adjust which sections are shown to which personas. This changes behavior: sensitive data exposure changes.
• •Password convention: change the recommended format. This is cosmetic: it only affects what you tell reps to type.

The site ID, workspace, persona list, field set, and visibility defaults all change what the agent builds. The password convention is the only item on this list that is purely cosmetic.