Build a client pilot you can review together

Give your client something they can try on their own website before they agree to a wider rollout. You'll build one question with two recommendations, review the draft together, and publish when they're happy with it.

This pilot doesn't collect email addresses or need an email-platform connection. Our example business, WorkForge (opens in a new tab), uses it to help visitors find the right page for their work.

1. Agree who owns the pilot

Choose one real client page and record what it shows now, including any existing widgets or campaigns. Keep the latest known-good published version as your recovery point.

Agree who will:

• Own the client's project, billing, and ongoing access.
• Approve the script, data collection, consent requirements, security review, and website changes.
• Build the draft and review its copy, links, and desktop and mobile layout.
• Approve and publish the complete project draft.
• Measure clicks and any later business activity.

These are responsibilities you agree with the client, not special permission roles in RightMessage. Also agree who will remove access when the pilot ends.

Select the client's project and check its name and website with the owner. Don't build it in another client's project or an agency demonstration project.

2. Give your reviewer access

Project access lets your client inspect the questions and offers as well as try them on the website.

1. Have the project owner open Settings, then Collaborators.
2. Review People With Access.
3. Under Add Someone New To This Project, enter the approved reviewer's email address and choose Invite.
4. Check for the sent notification and confirm the reviewer can open the intended project.

Enlarge

Collaborators settings with example member Alex Rivera and the invitation formOriginalOriginal

The invitation sends immediately, not when you publish. It grants editing access, not view-only access. If the reviewer shouldn't be able to edit, review the pilot together instead of inviting them. Don't share a login.

If RightMessage asks you to verify your own email, do that before sending. An invitation error means access hasn't been granted. Collaborator access covers invitations and removal.

3. Add RightMessage to the approved page

The project snippet lets your draft run on the client's real website, so they can see how it fits the page.

Give the site owner the production domain, pilot page, and planned data collection. This pilot saves anonymous answers and shows links. Complete the client's script, consent, security, and deployment review before installation. Use their actual requirements rather than assuming a consent exemption or a particular Content Security Policy change.

1. Open Settings, then JavaScript Snippet.
2. Keep Live website selected for the production site.
3. Have the site owner install the displayed snippet in the <head> of the approved pages. Check for an existing copy first.
4. Visit the site normally, then check Snippet Health. A recent timestamp means RightMessage received activity.

If your client requires staging first, use Staging / development and follow the live and development snippet reference. That snippet uses an authorized draft debugger session and disables analytics, so check the loaded draft rather than waiting for a new health timestamp. Provider writes in the debugger are simulated.

You can prepare the draft while approval or installation is pending. Mark the on-site check as unverified until you can try it on the actual website.

4. Ask one question and recommend two pages

Pick two pages on the client's website and ask what you'd need to know to recommend each one. WorkForge could ask "Who's doing the client work?" and send an agency team to its agencies page (opens in a new tab), or a solo consultant to its consultants page (opens in a new tab).

1. Open Flows, choose New flow, then Blank flow.
2. Choose A new widget if offered, select Inline, and enter WorkForge client pilot in Flow name. Choose Create flow.
3. Open the attached widget and turn Enabled off. New widgets start enabled, and another collaborator's publish could include it.
4. On the flow canvas, choose Add the first step, then Question and Multiple choice.
5. Enter your question and two answers. For WorkForge, use An agency team and Just me.
6. Leave Allow multiple answers off and choose Add to flow.
7. On each answer's path, add an Offer and choose Create a new offer / promo.
8. In Content, write the Headline, Description, and Button text. Set Link URL to the matching page.

For example, WorkForge's agency offer could say "Keep your team's client projects together" with a "See WorkForge for agencies" button. Write copy that describes what the linked page actually offers.

If separate answer paths aren't present, use Route off this question. If you see a Default path, add a general offer there so a skipped or unknown answer still has somewhere useful to go. The Question and Router reference explains those paths.

In the widget's Display tab, set Question handling to Ask questions we don't know the answer to. This lets returning visitors reuse an answer. Include that choice in your review notes.

Keep this pilot free of email capture. Adding it later needs an agreed contact, consent, provider, and answer-sync setup.

5. Choose a spot on the page

Use the built-in placement picker so the site owner doesn't need to paste widget code into the page.

1. In Display, open Where it appears.
2. Choose Pick spots on your site, then Pick a spot.
3. Browse to the approved pilot page and choose the agreed position.
4. Check the saved domain and Path is rule so the widget appears only on that page.

Keep the page's existing content and main action useful without the widget. Check that the new placement doesn't compete with another widget or campaign.

6. Preview it with your client

Give the reviewer the project, flow, widget, page, copy, and destination links. Keep private preview links within the agreed review group.

1. Turn Enabled on in the draft when everyone who can publish knows you're reviewing it.
2. Choose Preview on your site in the bottom bar. Use Choose preview URL to open the pilot page.
3. Take both answer paths normally and open each destination.
4. Use the debugger docked at the bottom to see the saved answer and the path RightMessage follows.
5. Check desktop and mobile, returning visits, and any skipped or unknown-answer path.
6. Visit an unrelated page and confirm the widget isn't there.

Testing your changes explains how to try each path as a fresh visitor. Record what you expected and what you saw, with a pass, fail, or unverified status for each check. A preview link nobody opened is still unverified.

Keep the review date, reviewer's name, widget state, approved destinations, remaining dependencies, and recovery version together. Fix failed checks before asking for approval. If a check is blocked, name the person who can complete it. Turn Enabled off again if the pilot isn't ready for publication.

7. Publish the approved draft

Have the release owner review all pending changes, including work from other collaborators. Publishing includes the whole current project draft, not just the flow you're looking at.

1. Confirm the pilot widget's Enabled switch is on. Keep unrelated unfinished widgets and campaigns off.
2. Choose Publish in the bottom bar and review the target site and grouped changes.
3. Resolve validation or plan warnings, including dependencies introduced by other pending work.
4. Enter a Publish note naming the pilot and its approved scope.
5. Confirm that nobody has changed the draft since review, then publish. If it changed, ask the reviewer to check it again first.

Enlarge

Publish validation explaining that forms need an email integration before the draft can go liveOriginalOriginal

The screenshot shows a form blocking publication because it needs an integration. This no-capture pilot doesn't need one, but another pending change might.

Include campaign activation, forms, and System Flows in the review. A published System Flow can run without an enabled widget. Invitations and website installations already took effect separately. Drafts and publishing explains that boundary.

Keep the recovery version and its owner in the handoff. Restoring a backup replaces the project draft and can overwrite other pending work. It doesn't reverse invitations, provider writes, or external sends.

8. Hand it over

Check the publish entry in project history. Then visit the pilot page normally, without forced segments or debugger data. Take both paths, check the unrelated page again, and confirm the original page works without interacting with the widget.

Give the owner the project and resource names, review record, publish entry, recovery point, access list, and measurement definition. Say which checks covered the draft, the preview, and the published website. Keep any unverified follow-up activity separate. A resource click doesn't mean someone read the page or became a customer.

When visitors can answer the question and open the right page, and the client knows what was published and who owns it, the pilot is working. Next, review how visitors use the flow. Agree another page or audience with the client before expanding it.