From Demo Click to Human Reply in 60 Seconds: A Sales Handoff Journey for Shopify Apps

The worst place for a hot lead to sit is in your inbox.

Picture this: it’s 11:07 a.m. on a Tuesday. A seven-figure Shopify brand hits your pricing page for the third time this week, clicks “Book a demo,” and fills the form. They’re comparing you against two competitors. Whoever replies first with a clear next step will probably win.

Your current system? A form notification to a shared email, maybe a Slack ping. Someone on your tiny team sees it… at 11:31. By then, they’re in a meeting. The first real response goes out hours later. Half the time, the prospect has already picked a slot with someone else.

The sequence at the top of this page is the whole journey, end to end. It exists to kill that lag.

We’ll walk through how a Shopify app like CartWizard (cart recovery + upsell, $98k MRR, four-person team) can route every demo request into:

• An instant, polished confirmation email to the prospect with a calendar link.

• A context-rich internal email to the sales queue, so the right human follows up fast.

• A short follow-up branch for prospects who don’t pick a time.

All built in Spreeflo’s campaigns and journeys editor, and all wired to your actual product usage data.

This pattern hits two things you care about: keeping every detail about a prospect in one place so you can speak to them specifically, and buying back founder time without hiring a sales team.

What this journey is really solving

Before we get into nodes and triggers, it’s worth being explicit about the leak this fixes for most e‑commerce app developers:

• Demo requests are rare but high intent: conversion from “asked for demo” to “became a customer” is usually your highest-performing path.

• Response time is all over the place: because you’re juggling product work, support, and feature launches.

• Information is scattered: form tools, support inbox, CRM, and Stripe all know something about the contact, but nothing is stitched together for the person running the call.

This journey fixes those three points:

1. Any expression of “I want to talk” is treated as a first-class behavioral trigger.

2. Every request gets an immediate, consistent response, both internally and externally.

3. The internal email carries a rich profile pulled from what you already track, so the conversation starts at the right altitude.

Let’s go through the journey step by step.

Step 1: Two triggers for how demo intent actually shows up

Look at the top of the sequence: there are two entry points, not one.

You probably have at least two ways someone can raise their hand for a demo:

• A manual action in your stack adds a tag like book-demo to the contact.

• A custom event like demo_requested fires when they submit a form in your app or on your marketing site.

We treat both as first-class.

Trigger A: Added Tag – “book-demo”

The first trigger is an Added Tag trigger configured for your “book demo” tag.

Why start with a tag?

• Tags are easy to add from anywhere: Intercom, your admin dashboard, even a CSV import.

• They’re human-readable and easy to reason about later (“everyone tagged book-demo).”

In Spreeflo, you’d:

• Add an Added Tag trigger.

• Select your book-demo tag.

• Turn Re-enrollment on.

Re-enrollment matters here. The same store might request multiple demos over time (different stakeholders, new features, onboarding a second brand). With re-enrollment on, every new tag event can send them back through this journey, provided they’re not already mid-flow.

If you’re not using tags heavily yet, this is a good excuse to start. The guide to getting started with tags shows how to organize your contact labeling so flows like this stay maintainable as you grow.

Trigger B: Custom Event – `demo_requested`

Not every demo request comes from a tool that can push tags. Sometimes it’s just a form on your site wired to your backend.

That’s what the Custom Event trigger is for.

• Event name: demo_requested.

• Re-enrollment: on.

• Optional property filters: maybe only fire when plan is Pro or Enterprise, or source contains pricing_page.

Your app or site emits this event through the tracking snippet or server-side via the Spreeflo API. Either way, the event becomes a first-class trigger in the journey.

Again, re-enrollment is on. If the same admin hits “Book demo” twice because they didn’t see the confirmation the first time, you want the system to behave as if it’s fresh every time.

Why both, not one?

You could force everything through either tags or events alone, but real stacks are messy. Partners might add a tag via API, your marketing site might send an event, and your success team might tag contacts manually.

Supporting both keeps you honest: any clear signal of demo intent enters this flow, without you re-architecting every upstream tool.

On the canvas, both triggers point into the same Merge node. That keeps the journey maintainable—everything from that merge onward is your single source of truth for “what happens after someone requests a demo”.

Step 2: Merge to a single, canonical handoff path

The Merge node has no configuration. It just says: “regardless of how you got here, from now on you’re treated the same.”

The alternative would be duplicating the entire flow for each trigger, which is how flows silently drift over time. One path gets an updated calendar link, the other doesn’t; one path tags the contact correctly, the other forgets.

Merge first, then design once.

From the Merge, everyone flows into the contact-facing confirmation.

Step 3: Instant confirmation email with a clear next step

Immediately after Merge, the sequence uses a Send Email action. This is the email your prospect sees in their inbox seconds after clicking “Book demo”.

Built in Spreeflo’s email builder, it typically does four jobs:

1. Confirms the request: “We’ve got your demo request for CartWizard.”

2. Sets expectations: “We run 30-minute calls focused on your current setup and your upsell goals.”

3. Provides a primary next step: a Calendly or SavvyCal link, or a reply-based scheduling CTA.

4. Reassures they’re talking to humans: maybe you sign it with a real founder or AE name, not “The CartWizard Team”.

You’ll likely turn off the “send only once” toggle in this node. In Spreeflo, that setting prevents the same email from going to the same contact more than once across the entire journey, even on re-entry. For demo confirmations, that’s too strict; if they ask for a second demo six months later, they should see a fresh confirmation.

This is also where you start speaking to them uniquely:

• Use stored attributes like store name or current plan in the subject and opening line.

• If you track primary category, reference it: “Let’s talk about how high-traffic fashion brands use CartWizard.”

The richer your contact data, the more specific you can be. This is why Spreeflo leans so heavily into detailed contact attributes and events: the more you know about how a store uses your app, the less your emails sound like they were written for “everyone”.

Immediately after this contact email, the sequence sends an internal alert.

Step 4: Internal email that gives your team context, not homework

Next in the path is Send Internal Email.

Same channel (email), different audience: your team.

This message goes to whatever internal address you choose—maybe a round-robin group like sales@yourapp.com, or directly to the founder while the team is small.

The goal: when someone opens this, they have enough context to handle the demo without hunting around in five tools.

Typical contents:

• Contact name and email.

• Store URL.

• Current plan and MRR band (if you track it).

• Where they requested the demo from (pricing page vs inside the app).

• Any key feature events: “Has used ‘multi-step upsell’ 14 times in last 30 days; hasn’t tried ‘A/B experiments’ yet.”

• A direct link to the contact record in your admin.

Because Spreeflo’s contact timeline already captures events, tags, and attributes, you don’t need a custom report. The internal email can simply deep-link into the contact, and whoever owns the demo can scan their activity there.

Again, you’ll usually turn off “send only once” here so repeated demo requests create repeated alerts.

Up to this point, the journey has done the “instant” part of the pattern: both emails fire as soon as the trigger happens. Next, you make sure you only nudge when it’s actually needed.

Step 5: Wait up to 24 hours for them to book

You don’t want to nag someone who already picked a time. You also don’t want demo requests stalling indefinitely because they never completed the scheduling step.

That’s where a Wait Condition comes in.

Right after the internal email, the journey pauses on:

• Condition: contact has either triggered a demo_scheduled custom event at least once, or been tagged with something like demo-booked by your calendar integration.

• Timeout: 24 hours.

Under the hood, that condition uses Spreeflo’s segment builder: a small OR group combining a Custom Events rule (demo_scheduled at least 1 time) and a Tags rule (contact is tagged with demo-booked).

Two wins here:

• The Wait Condition doubles as spacing. It satisfies the “no back-to-back marketing emails” rule in the journey, so any follow-up email later won’t feel like spam.

• It gives your metrics teeth. You can compute demo-booked rate simply as “contacts who satisfied this condition” divided by “contacts who entered the journey”.

If the condition is met within 24 hours, the contact moves on immediately. If not, they proceed when the timer expires. Either way, the next node is the same: an If/Else split.

Step 6: If/Else split – booked vs not booked

After the wait, the journey uses an If/Else process node with the same condition you just used in the Wait:

• Yes branch (“then”): condition is true, demo is booked.

• Else branch: no matching event/tag; they haven’t scheduled yet.

You might wonder why we repeat the condition here after the Wait just used it.

The reason is clarity.

• The Wait Condition answers: “Should we keep waiting or move on?”

• The If/Else answers: “Now that we’ve moved on, which path describes this contact?”

It also keeps the canvas more readable later. Anyone scanning your journey can instantly see “booked vs not booked” as distinct branches.

Let’s take each branch.

Step 7A: For booked demos – tag, log, and optionally ping again

On the “booked” branch, the goal isn’t more messaging. It’s better data and cleaner routing.

Common actions here:

1. Add Tag: apply demo-booked if you’re using an event-based condition earlier. This creates a quick segment you can reuse in other automations: “post-demo onboarding,” “closed-won tracking,” and so on.

2. Update Contact Attribute: set a sales_stage attribute to a literal like "demo_booked". That gives you a simple SDR-style pipeline view with attributes: requested → booked → held → converted.

3. Optional Send Internal Email: if your scheduling tool doesn’t already send calendar invites to your team, fire a second internal email that says “Demo booked for {date/time}” so no one misses it.

Notice what you don’t do here: send another email to the prospect. They’ve already booked and received whatever confirmation your calendar product sends. Anything else risks cluttering their inbox.

After those actions, this path ends. The contact exits the journey.

Step 7B: For stalled requests – a single, respectful nudge

On the “not booked” branch, you use the one follow-up that actually moves metrics: a short reminder.

Because the last marketing email they saw was the initial confirmation, and you’ve had a 24-hour Wait Condition in between, you’re clear to send another Send Email here.

This email can be very simple:

• Subject along the lines of “Still want to see CartWizard in action?”

• Body that reminds them they asked for a demo, re-states the value, and links to the same calendar.

• A plain reply option: “If it’s easier, just reply with a couple of good times and we’ll make it work.”

You can also:

• Add Tag: demo-nudge-sent so you know they needed a reminder.

• Keep “send only once” on for this node, even if it’s off for the initial confirmation. If the same store re-requests a demo later, you might send confirmation every time, but they don’t need multiple reminders for the same ask.

Then this branch also ends. At that point, every contact has either booked, been nudged, or both.

Measuring whether this works

This pattern is built around three metrics:

• Demo-booked rate: of everyone who triggered book-demo or demo_requested, what percentage reached the “booked” branch?

• Meeting-held rate: of everyone who booked, how many actually showed up?

• Time-to-contact: how long between the trigger and your first touch (email or human)?

The first is easy inside Spreeflo: create segments based on journey entry and tags, then compare sizes. Or build a quick report off your sales_stage attribute.

For meeting-held rate, emit a demo_held custom event from your backend or via your scheduling tool webhook, and either:

• Build a small second journey triggered by Custom Event demo_held that tags the contact and sends a “Thanks for your time” recap, or

• Use the event directly as another condition in your segment builder queries.

Time-to-contact is effectively zero for the automated confirmation and internal email. The only remaining lag is when a human actually responds, which is why that internal email is so rich: no one has to dig around before hitting “reply.”

Why this is a founder’s friend, not another system to babysit

If you’re running a Shopify app like CartWizard or ShopMetrics, you already have enough complexity in your life: app reviews, the next feature, the Shopify API changing, partnership calls.

This journey gives you a different kind of asset:

• You define once what “a good sales handoff” looks like.

• Spreeflo enforces it every time someone raises their hand.

• Your contact data gets a little richer with each pass: more tags, clearer stages, more behavioral events to personalize around later.

Because it’s all sitting in one place—the same contact record that powers your campaigns and lifecycle sequences—you never have to choose between “fast response” and “speaking like you actually know who this store is.”

And it doesn’t require headcount. With a couple of triggers, a Merge, a handful of actions, and some thoughtful copy, you get behavior-driven sales handoff that works at 100 customers and 10,000.

If you’re already sending newsletters or basic onboarding, this is often the next most valuable automation to add. Open your account, go to the campaigns and journeys editor, wire up an Added Tag and a Custom Event, and make sure every “Book demo” click from now on gets the response it deserves.