Connect by JBRH Open Connect

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 What this means
Audience
both
Channels
emailwhatsappphone
In the app
#/follow-ups, #/relationships, #/autonomy
Last verified
Product version
6.3.2

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:<channel> 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.

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.