# Software trials and onboarding Connect can run the human half of a trial: the check-in that references what somebody actually asked, the answer grounded in your documentation, the follow-up that stops the moment they reply. What it cannot do by itself is know what they did inside your product — there is no telemetry integration, so usage reaches the workspace as data you put there or not at all. - **Status:** Available - **Audience:** both - **Channels:** email, whatsapp, phone - **In the app:** #/follow-ups, #/relationships, #/autonomy - **Last verified:** 2026-09-10 - **Canonical:** https://connectbyjbrh.com/docs/use-cases/saas-trials/ ## The gap that decides whether this works Good trial messaging is behavioural: it says something different to somebody who has connected a data source than to somebody who signed up and left. Connect has no view into your application. The capability registry carries no product-analytics integration, and inventing one in prose would be the kind of claim this documentation exists to avoid. - **What Connect knows by itself**: every message, call and commitment on the relationship, the lifecycle stage, the onboarding actions recorded against the person, and anything written as memory. - **What has to be supplied**: activation state, feature usage, seat counts, anything from your own database. A data sheet, a periodic upload, or a workspace integration key on your side. - **What follows from that**: a trial nudge grounded in conversation is honest and useful; one that pretends to know what somebody clicked is guessing, and customers can tell. ## Nudges that are worth receiving 1. Set the sequence up as follow-ups with reasons rather than as a broadcast schedule. - Result: Each one explains itself to whoever picks it up, and duplicate protection applies — a follow-up with the same due time for the same person is a duplicate and does not become a second message. 2. Run the first cohort on `draft_only`. - Result: Connect writes what it would send and asks nobody. You read a week of real messages against real accounts before anything goes out, which is a far better test than reviewing a template. 3. Ground every claim about your product in Knowledge. - Result: Answers come from your documentation. What Knowledge does not support is refused rather than paraphrased from the model's general impression of software like yours. 4. Let a reply take over from the sequence. - Result: An inbound reply is handled as a reply, on its own gate. Outreach and customer replies are two paths that are never merged, which is what stops somebody receiving day-five's nudge after asking a question on day four. ## The stop rules, which matter more than the sends **They replied** — The conversation takes precedence. A cold sequence has an explicit stop, and stopping for a thread or for a person are both available as operations rather than as a manual tidy-up. **They asked to stop** — Opt-out is honoured and recorded like any suppression, on whichever channel it arrived. On SMS, STOP is handled even though outbound does not run on the live carrier. **They are on the do-not-contact list** — Checked in one place before any outreach. Clearing an entry is a person's decision, recorded against them; the Assistant cannot clear one at all. **A block directive exists** — A `connect_memory` row tagged `block:` holds across channels and future conversations — stronger and broader than a suppression, and cleared separately. **The allowance is spent** — Held rather than dropped, with the refusal visible in Needs You. A sequence does not silently skip a day. > **Note** The difference between a nudge and a nag is almost entirely whether the stop rules fire on the first signal rather than the third. Every one of these is checked before a message exists, not after it is written. ## What must not be automated The save. When a trial is about to lapse, the temptation is to let software offer an extension or a discount, and `safe_sales` refuses exactly that: a price, an SLA or a warranty Knowledge does not support is refused and escalated to a person. Published terms are facts and can be repeated; a concession invented to keep an account is a commitment your business then has to honour. The same boundary covers roadmap answers. 'Will you support X' has no source unless you have written one, and a promise about the future is the class of claim this system is built to refuse rather than soften. ## Where the money goes Cheap, if it stays written. A trial sequence is a handful of model calls per account, grounded in a record that is already loaded, and the plan's daily allowance is the ceiling. It becomes expensive the moment somebody decides to ring every expiring trial: audio tokens run at four times the text input rate, roughly 2.7× on output, and a Live session is re-billed for its whole context on every turn. Call the accounts that replied. ## Questions ### Can it see whether a trial user has activated? Not by itself. There is no product-analytics or telemetry integration in the capability registry. Activation state has to reach the workspace as data — a sheet you maintain, a periodic upload, or a push from your own systems — and once it is there it can be queried like any other record. ### Will it stop messaging somebody who replies? Yes, and this is structural rather than a setting to remember: outreach and customer replies are two separate paths with different gates and are never merged, and a cold sequence has an explicit stop for a thread or for a person. An opt-out is recorded as a suppression on the channel it arrived on. ### Can it offer a discount or an extension to save an account? No. Commercial terms that Knowledge does not support are refused and escalated to a person. If your published policy includes a fourteen-day extension on request, that is a documented fact and can be offered; a bespoke concession is a decision with your name on it, not the model's. ## Related - [Onboarding a new customer](https://connectbyjbrh.com/docs/support/onboarding/) - [Stopping a cold sequence](https://connectbyjbrh.com/docs/prospects/cold-sequence-stop/) - [Duplicate follow-ups](https://connectbyjbrh.com/docs/follow-ups/duplicates/) - [The four autonomy modes](https://connectbyjbrh.com/docs/autonomy/modes/) - [Claims Knowledge does not support](https://connectbyjbrh.com/docs/knowledge/unsupported-claims/) - [Lifecycle stages](https://connectbyjbrh.com/docs/relationships/lifecycle-stages/) ## What this page is based on - Connect capability registry (docs-source/facts.py) - docs-source/sources/CHANNELS.md §1, §4 and §7 — compliance, sequences, follow-ups - docs-source/sources/GENERAL.md §5 and §6 — autonomy modes and block directives - docs-source/sources/CHANNELS.md §6 — safe_sales