Onboarding Blueprints let you build the ideal client account once, then reuse that setup automatically every time a new customer connects their first review source.
The point is simple: reduce repetitive setup work, help customers see value faster, and make the platform feel more complete from day one.
What onboarding blueprints are
Blueprints are reusable templates that auto-create assets for new customers. Instead of manually building the same feedback form, campaign, and widget for every client, you build them once and let the platform clone them automatically.
The trigger is the customer connecting their first review source. When that happens, the system checks the active blueprints and creates the matching items inside that customer account.
- Feedback Form blueprints create a ready-made form
- Campaign blueprints create a ready-made request sequence
- Widget blueprints create a ready-made review display
Where to find it
Go to `AI & Automation -> Onboarding Blueprint` in the sidebar. This is an agency-only workflow used to design default client setups and apply them automatically.
How it works in practice
The workflow is simple. Build something strong for one client, save it as a blueprint, then let the platform recreate that setup for the next customer who connects a review source.
- You build a feedback form, campaign, or widget that you want to reuse
- You create a blueprint and choose that entity as the source
- A new customer signs up and connects their first review source
- The platform checks active blueprints, plan fit, and permissions
- The configured entities are cloned into the customer account automatically
Blueprints apply once per customer. They are not meant to re-run every time the account changes.
The three blueprint types
Each blueprint type maps to a different part of the client experience. Most agencies eventually use all three together because that gives the customer a collection asset, a sending asset, and a display asset immediately.
- Feedback Form blueprint: creates a ready-made review collection form
- Campaign blueprint: creates a pre-built review request campaign
- Widget blueprint: creates a ready-made review display widget
Create your first blueprint step by step
Start by building the template entity first. Many agencies use a template organization or dummy client account so they can perfect forms, campaigns, and widgets without touching real client accounts.
Then go to `AI & Automation -> Onboarding Blueprint`, click `Create Blueprint`, name it clearly, optionally tie it to a specific custom plan, choose the type, and save.
After creation, the blueprint edit modal opens immediately. This is where you select the existing feedback form, campaign, or widget that should act as the source.
- Give the blueprint a name that describes both purpose and audience
- Use the custom plan field if the setup should only apply to one plan tier
- Pick the correct type before saving because type cannot be changed later
- Select the source carefully because it becomes the frozen template snapshot
Understand the source snapshot rule
When you choose the source and save the blueprint, the system takes a full snapshot of that entity at that moment. Later edits to the original source do not update the blueprint automatically.
If you want a blueprint to reflect a new version of the template, delete the old blueprint, update the source, and create a fresh blueprint from it.
What a full onboarding suite looks like
A strong real-world setup usually combines one feedback form blueprint, one campaign blueprint, and one widget blueprint. For example, a dental agency might create a branded patient feedback form, a three-step review request campaign, and a polished review slider widget, then save all three as blueprints.
When a new dental client connects Google, all three appear automatically in their account and they reach a usable state almost immediately.
Using blueprints with custom plans
Blueprints can apply to all plans or to one specific custom plan. This is what lets agencies create genuinely different onboarding experiences by tier or vertical.
For example, a starter plan might only get a simple feedback form and badge widget, while a higher-tier plan gets a full campaign plus a richer widget.
- One blueprint can apply to all plans
- A blueprint can also be restricted to one specific plan
- Different plans can have different versions of the same blueprint type
Understand the uniqueness rule
The platform prevents duplicate blueprint conflicts by enforcing one blueprint per type per plan scope. That means you cannot stack two feedback form blueprints against the same plan scope and expect the system to choose between them.
- One feedback form blueprint for all plans is allowed
- One feedback form blueprint per specific plan is allowed
- You can still have one feedback form, one campaign, and one widget blueprint for the same plan because those are different types
Managing your blueprints
The blueprint dashboard shows the blueprint name, plan scope, type, status, and creation date. You can edit the name and active or paused state later, but the linked source cannot be swapped out after it is set.
- Running means the blueprint is active
- Paused means it will be ignored for new customers
- Setup not complete means no source has been selected yet
What gets copied and what does not
Blueprints clone the important configuration of the source entity, but they do not blindly duplicate every field. The customer account still gets its own IDs, its own context, and its own editable version of the created asset.
- Feedback form blueprints copy form structure, settings, negative feedback behavior, and field setup
- Campaign blueprints copy campaign steps, timing, duplicate prevention, and message structure
- Widget blueprints copy widget type, styling, filtering, and core display settings
- Customer-specific logos and IDs are not copied blindly. The customer context is applied instead
When blueprints fire
Blueprints fire when a customer connects their first review source. The system then checks whether blueprints have already been applied, whether the blueprint is active, whether the plan matches, and whether the customer plan actually allows the feature.
This is a one-time event per customer, not something that repeats for every location or every later review source connection.
If a customer already has the relevant entity or already had blueprints applied, the system avoids creating duplicates.
Best practices
- Start with one excellent feedback form blueprint before trying to automate everything at once
- If you use campaign blueprints, pair them with feedback form blueprints so the campaign has somewhere to send people
- Use plan-specific blueprints when the onboarding experience should genuinely differ by plan level
- Treat blueprints as the default starting point, not the final customisation state