Make a little space
for a better hello.

Start with one useful outcome

Choose between collecting an email, promoting an offer, sharing an announcement, or asking a short survey. A visitor should be able to understand the invitation and the next step in a glance.

Choose the least intrusive format that works

A sticky bar can carry a short announcement. An embed fits naturally into a page. A slideout works for a contextual invitation. A popup gives one message focused attention. A feed gives updates a visitor-opened home.

If your message works in a smaller format, try it there first. Use the live playground to compare how each format feels.

Write the whole conversation

The headline is only the beginning. Add useful body copy, a button that describes what happens, clear consent language where needed, and a success message that confirms the real outcome.

Do not promise an email delivery, discount, or download unless your connected systems actually provide it. Adding a coupon to a message does not create it in your commerce platform.

Give the message a sensible audience

Start with the pages where the invitation is relevant. Exclude checkout, login, or other focused workflows when appropriate. Then choose the device, visitor context, and campaign source rules that serve your goal.

A new visitor is new within the browser context, not necessarily a person your business has never met. Avoid using this audience label for identity or eligibility decisions.

Pick a moment and leave some room

Delay and scroll triggers let visitors look around. A click trigger responds to a deliberate action. Exit intent is useful only in the desktop pointer context. It should not be marketed as a reliable signal on a touch screen.

Choose a sensible session or daily frequency and use start and end dates for temporary messages. Test the campaign around your other popups, chat, and consent controls.

Test one question at a time

Basic experiments let you compare an alternative title and button with a traffic split. Changing several ideas together makes the result harder to interpret. Choose a metric first, allow time for ordinary variation, and do not call an early difference statistically significant.

FlexSprout does not currently provide automated significance decisions or revenue attribution. An observed conversion is an event, not proof that a sale was caused by the message.

Before you publish

• Check every destination URL and any discount code.
• Read the consent and success copy as if you were the visitor.
• Test the layout on narrow and wide screens.
• Verify keyboard use and the close control.
• Check the targeting, schedule, and frequency settings.
• Send a test capture and confirm its intended destination.

Need the website connection first? Start with the installation guide.

Connect the next conversation

Native Klaviyo, Mailchimp, and HubSpot connections are implemented with encrypted credential storage, discovery, explicit field mapping, consent-aware delivery, and recipient history/retry. Combined database/HTTP verification and actual credentials/provider receipts remain pending. A saved connection or successful read-only check does not prove a contact was written or a message delivered.

1. As an owner or admin, choose the website and provider, then supply an authorized credential. Mailchimp also needs its server prefix.
2. Discover and select the Klaviyo list or Mailchimp audience. Discover the writable properties for HubSpot.
3. Email is the contact identity. Map other values explicitly from name, phone, a classic survey answer, or a validated builder field such as fields.interest. Choose supported discovered merge fields/properties; missing values do not clear provider data.
4. Run the read-only connection check. It does not create a fake contact or prove write scopes.
5. Once external testing is separately authorized, submit a clearly labelled, consented test capture. Inspect both the recipient history outcome and the receiving provider before relying on the workflow.

Klaviyo and Mailchimp require recorded affirmative email-marketing consent with wording and a valid timestamp. Klaviyo request acceptance does not confirm subscription; ambiguous consent requests are not blindly resent. Mailchimp requests double opt-in for new contacts and preserves existing unsubscribe/status settings. HubSpot updates contacts without granting marketing subscription permission. Mapping a phone number never implies SMS consent.

Use the recorded outcome when deciding whether to retry. A failed recipient can be retried independently of successful destinations; retry is not a promise of delivery. CSV and webhooks also carry validated fields. FlexSprout does not send marketing emails or automatically backfill historical contacts.

Prepare web push explicitly

Web push is a separate locally implemented feature. Verification of the integrated runtime, coordinated migration, and UI remains pending, as do actual push-provider acceptance and device receipts. The onsite feed does not create a push subscription.

• Configure a matching VAPID public/private key pair and a real contact address. Missing or invalid configuration leaves push unavailable; saved drafts do not prove it is ready.
• Serve the FlexSprout worker at /flexsprout-push-sw.js from the customer website’s own origin. For an existing PWA or offline worker, integrate the namespaced handler into that worker instead of replacing it. The handler recognizes the flexsprout: 1 payload marker. Another provider’s subscription must not be silently overwritten.
• Use the separate push module with the main SDK’s admitted pageview proof. Show the exact push-consent wording with an unchecked checkbox, then request browser permission directly from the visitor’s trusted click or keyboard action. No automatic permission prompt on page load.
• Provide an unsubscribe control. Denied permissions, unsupported contexts, and worker/provider conflicts need explicit handling. Supported endpoints are allowlisted Google, Mozilla, and Apple push services; iOS/iPadOS Safari requires a supported Home Screen web app.

Limits are 500 active subscriptions per website, 500 recipients per send, and 10 queued sends per website per UTC day, including later-cancelled sends. Schedule at most 30 days ahead; notification TTL is 60–86,400 seconds. These technical limits do not change existing prices.

Cancellation stops queued/retrying work and later unstarted recipients; it cannot recall an in-flight or provider-accepted message. Delivery history distinguishes provider acceptance from expiry, failure, and cancellation. Acceptance is not proof of notification display, reading, or clicking. No deployment or remote sends have been performed for this expansion.