Handling a demo request, end to end

A demo request becomes two things: a demo record attached to the person and, usually, an opportunity; and a dated follow-up carrying the reason it exists. The confirmation to the customer goes out under the channel's autonomy rule. Connect writes no external calendar entry — the commitment is the record plus the message you send, and the follow-up is what makes anybody act on it.

Status: Available What this means
Audience: both
In the app: #/pipeline, #/follow-ups, #/needs-you
Last verified: 2026-09-10
Product version: 6.3.2

The chain, stage by stage#

Trigger — somebody asks to see it. In a reply, in a WhatsApp message, on a call, or from a person pressing Request demo on the record.
External event — the ask usually arrives inside an ordinary conversation rather than through a form, which is why detecting it is part of reading the thread rather than a separate intake.
Authentication and workspace resolution — settled before anything is read, because the pipeline, its stage rules and the follow-up queue all belong to one workspace.
Ingest — the message joins its canonical thread and the sender resolves to a person, so the request attaches to a relationship rather than to an address.
Canonical record — request_demo records the ask; schedule_demo records a time once one is agreed. Both hang off the person, and off the opportunity when there is one.
Reasoning — the reply is drafted against the whole conversation: what they asked about, what was already answered, and what still has to be established before a demo is worth anyone's hour.
Knowledge, memory and rules — what the demo covers comes from the workspace's Knowledge. safe_sales still applies, so a price or a warranty mentioned while arranging it is refused unless a source supports it.
Autonomy and approval — the confirmation is an outbound message like any other. ask_before_send queues it; autonomous sends it; draft_only prepares it and stops without asking.
Action through a provider — the confirmation goes out on the channel the request came in on, through the one send boundary a person's own reply uses.
Result — sent, failed, or uncertain. Uncertain is shown as uncertain, because sending a second confirmation to be safe is how a customer gets two.
Relationship, timeline and memory — the demo joins the person's timeline, and a follow-up is created with a reason so whoever inherits it knows what was promised.
Audit, usage and Needs You — the send is metered against the daily allowance, the decision is recorded, and anything held waits in Needs You until a person releases it.

Transition	What it records	What it does not do
`request_demo`	That a demo was asked for, and when	Commit anybody to a time
`schedule_demo`	The agreed time on the record	Write to an external calendar
`complete_demo`	That it happened, and what followed from it	Move the opportunity by itself
`cancel_demo`	That it will not happen, on the record rather than in a memory	Cancel the follow-ups you created around it

What actually holds the commitment#

The demo record is the fact; the follow-up is the pressure. A time written on a record reminds nobody, so the useful half of this flow is the dated commitment beside it — and a follow-up carries a reason, because a bare date is close to worthless to the colleague who picks it up on the morning it comes due.

Follow-ups run on email, whatsapp, sms, phone, any, or task. The task channel is work for a person: no drain ever sends it, and it appears as "For a person to do". Preparing an account before a demo belongs there. Reminding the customer the day before belongs on the channel they have been writing on.

Duplicate protection is deliberately blunt: a follow-up with the same *when* for the same person is treated as a duplicate. That stops a rescheduled demo accumulating three reminders, and it is the reason to move an existing follow-up rather than create a fresh one when a time changes.

Arranging it by phone#

A phone follow-up is drained by the engine every tick, two at a time, through the same gates any outbound call passes. Each attempt is recorded as a call placed, as awaiting approval, or as refused with the reason.

Two rules matter when a demo is being arranged this way. A line that is not ready is retried in an hour rather than abandoned. And a row that is more than twenty-four hours late is closed as missed and never rung, because a call-back that arrives two days after it was promised does more damage than the silence would have.

If the demo itself is a call, the transcript and summary attach to the person like any other, and the outcome you record on complete_demo is what the pipeline reads — not the fact that a call happened.

Where it goes wrong#

The customer never got a confirmation: The channel is on draft_only, which prepares the reply and deliberately queues nothing. The text exists on the conversation; nobody was asked to release it.
Two reminders reached the same person: Two follow-ups with different times survived a reschedule. Move the existing one instead of adding another; the duplicate rule only catches an identical *when*.
The demo is on one record and the history on another: The request arrived on an address that is not attached to the person you are looking at. Merge the duplicate before scheduling, so the demo, the deal and the conversation end up under one name.
It was never rung: The follow-up went past twenty-four hours late and was closed as missed. That is the rule working; re-create it with a time you can keep.
The opportunity did not move: Completing a demo records an outcome; it does not advance a stage. Stage rules govern that move, and they are a separate, deliberate decision.

Questions#

Does Connect put the demo in my calendar?

No, and no page here should suggest otherwise. The agreed time lives on the demo record and, if you created one, on a follow-up that will surface it when it comes due. Any calendar invitation your customer accepts is one a person sends.

Can Connect agree a time without asking me?

That depends on the channel's autonomy mode and on the narrowest scope that applies — a rule set against one contact beats the channel's. On ask_before_send every confirmation waits for a human yes; on autonomous it goes out within the gates. Either way a commercial term mentioned in passing is still refused unless Knowledge supports it.

What is the difference between the demo record and the follow-up?

The record says a demo was requested, scheduled, completed or cancelled. The follow-up is a dated commitment with a reason, on a channel, that somebody or something will act on. You can have one without the other, and a demo with no follow-up is the one most likely to be quietly forgotten.

Someone asked for a demo on the phone. Is that handled differently?

The record and the follow-up are identical. What differs is that a call gives you a transcript and a summary attached to the person, and that arranging a call-back is itself a phone follow-up, drained two per tick and closed as missed if it goes a day late.