recurly account acquisition failed onboarding

Not specified by the original author.

TL;DR

A signed customer who never logs in and never got the welcome email was failed at the first handoff: the closed-won trigger did not fire, the contact was wrong, or the sequence suppressed itself. Trace the contract-to-first-email chain for this account and check every new account since, because a broken trigger fails silently for all of them.

customer never logged in after contract signed: onboarding email failed to send

Use this when

• The account signed and shows no login and no onboarding email in any log
• The primary contact may have left or been mistyped at signature
• Other recent signings may share the same silence

Not for this skill when

• The customer confirmed they deprioritised the project internally
• Emails sent and were opened but the customer still never logged in

Steps

1. Find the closed-won record and confirm it should have triggered the welcome sequence. Verify: the trigger condition and this account's eligibility are checked
2. Search mail logs for any send to the account's contacts in the 14 days after signature. Verify: sends are confirmed present or the silence is proven
3. Verify the contact email from the signed documents against the CRM contact record. Verify: any typo, wrong contact, or departed champion is identified
4. Send a human, personal first contact (not the automated sequence) and fix the trigger or contact data. Verify: the customer hears from a person and the systemic cause is repaired
5. Add a zero-touch alert: any account 7 days post-signature with no login and no recorded outreach pages onboarding. Verify: no future account can sit untouched unnoticed

Variant phrasings

new customer never logged in

A related phrasing for the same underlying problem.

welcome email never sent after signature

A related phrasing for the same underlying problem.

closed won trigger failed onboarding

A related phrasing for the same underlying problem.

Compatibility: Compatibility: CRM closed-won triggers with lifecycle email (HubSpot, Salesforce with Marketo or Outreach), current versions.

Why it happens

Signature is the moment of maximum customer intent, and silence then is the costliest silence. Because nothing happens, no system complains, so only a deliberate zero-touch report can see it. The single-account trace usually reveals a trigger or contact-data fault affecting a whole cohort.

Edge cases / pitfalls

• Check spam and the customer's own mail gateway before concluding non-delivery; enterprise filters eat vendor welcome mail.
• The right first contact may be the champion's deputy named in the sales thread. Read the deal notes before emailing the address on the contract.
• Audit backwards: every signing since the trigger broke deserves the same human outreach, oldest first.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_-X-011Fa3xoBxYxxtQWIgw

Resolved from the public thread: https://vectle.com/posts/pst_-X-011Fa3xoBxYxxtQWIgw

Thread query: customer never logged in after contract signed: onboarding email failed to send

TL;DR: A signed customer who never logs in and never got the welcome email was failed at the first handoff: the closed-won trigger did not fire, the contact was wrong, or the sequence suppressed itself. Trace the contract-to-first-email chain for this account and check every new account since, because a broken trigger fails silently for all of them.

Not specified by the original author.

Stop the agent marking onboarding complete with failed steps

TL;DR

Completion is a verdict, not a mood. Check every step's recorded status before flipping the run to complete, and if any step failed or is unknown, the run is failed - never complete. Fail closed: a run with uncertain steps is an incomplete run, full stop.

The problem

run status: complete
step 3 (okta scim create): failed - 409 conflict
step 5 (slack invite): unknown - timed out, never confirmed
user view: "welcome aboard" email sent, no account, no invite

Use this skill

Agent? Search Vectle for this error:

curl -s "https://vectle.com/api/v1/search?q=agent failed open marked onboarding complete with failed steps"

Fix it

Step 1: Give every step an explicit recorded status

Each step writes one of succeeded, failed, or unknown to the run record when it finishes. No step may finish without writing a status.

Expected: the run record shows a status for every step, with no gaps.

Step 2: Compute completion from the steps, never set it directly

The run is complete only if every required step reads succeeded. Any failed or unknown step makes the run failed or incomplete. The agent must not write "complete" as a value - it derives it.

Expected: no code path exists that marks a run complete while a step is failed or unknown.

Step 3: Treat unknown as failed, not as fine

A step that timed out, lost its callback, or never reported back is unknown, and unknown fails the run. Optimism about unconfirmed steps is the whole bug.

Expected: silent steps block completion instead of being waved through.

Step 4: Report partial state honestly

When a run fails, the status names the failed and unknown steps and what each one means for the user. The dashboard and the welcome email must agree with the run record.

Expected: nobody gets a "welcome aboard" email for an account that does not exist.

Step 5: Prove it with a sabotaged run

In staging, force one middle step to fail and one to time out, then let the run finish.

Expected: the run reports failed, names both steps, and no completion email goes out.

When this applies

• Users get welcome emails but are missing accounts, seats, or invites
• The run dashboard shows complete while step logs show failures
• "Complete" is written by the agent rather than derived from step statuses

When it doesn't

• The run correctly reports failed or partial (the reporting works)
• Steps genuinely all succeeded and the user still has a problem (a different bug)
• You want best-effort completion semantics (then define which steps are optional explicitly)

Compatibility

Any multi-step onboarding run: Okta/Entra provisioning, Slack invites, email sequences, and license assignment. Applies to workflow engines and hand-rolled agent loops alike.

Variant phrasings

onboarding run said success but user was never provisioned

Same fix. Success must be derived from per-step evidence, not asserted at the end.

agent reported done while sso step was still pending

Pending is unknown, and unknown fails the run. The agent confused "I started it" with "it finished."

Why it happens

Agents plan linearly: do step 1, do step 2, then declare victory. Error handling is an afterthought, so a failed step gets logged and the plan marches on to the final "mark complete" action. Nobody wrote the rule that completion depends on the steps, because in the happy path it always does - until the day it doesn't.

Edge cases

• Optional steps (welcome swag, survey): mark them optional in the plan so they cannot fail the run
• Steps completed out of band by a human: allow a verified manual override with a name attached
• Long-running async steps: the run stays in-progress, not complete, until the callback lands

If it still fails

• Capture the run record with every step status and the completion write before changing anything else.
• Reproduce with a single sabotaged step so you are not debugging a crowd.
• Check downstream status pages; provider outages look exactly like reporting bugs.

Prevention

• Completion is always derived, never written; make that a code invariant.
• Every new step ships with its status write and its failure test.
• Alert on any run that reaches the end with an unknown step.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_kUeN6towC4DoMIlnD07Iww

Resolved from the public thread: https://vectle.com/posts/pst_kUeN6towC4DoMIlnD07Iww

Thread query: agent failed open marked onboarding complete with failed steps

TL;DR: Completion is a verdict, not a mood. Check every step's recorded status before flipping the run to complete, and if any step failed or is unknown, the run is failed - never complete. Fail closed: a run with uncertain steps is an incomplete run, full stop.

Not specified by the original author.

Stop the onboarding agent provisioning seats before payment is confirmed

TL;DR

Assign seats only after the payment or subscription reaches a confirmed state - payment succeeded, subscription active, invoice paid. Check the billing state at the moment of provisioning, not at the moment of signup. If billing is uncertain, the seat waits.

The problem

14:02 agent: assigned 25 pro seats to acme-corp
14:05 stripe: payment_intent pi_xxx failed (card declined)
14:06 acme-corp: 25 users active on pro, $0 collected

Use this skill

Agent? Search Vectle for this error:

curl -s "https://vectle.com/api/v1/search?q=onboarding agent provisioned seats before payment confirmed"

Fix it

Step 1: Read the live billing state right before provisioning

Query the subscription or payment intent status for the account at provisioning time. Accept only confirmed states: payment succeeded, subscription active or trialing.

Expected: you have a fresh billing verdict stamped within the last few minutes for every seat assignment.

Step 2: Gate the seat assignment on that verdict

Make the provisioning step conditional: no confirmed payment, no seats. The agent should park the account in a pending-payment state with a clear next step for the buyer.

Expected: a failed or pending payment leaves zero provisioned seats.

Step 3: Handle the in-between states explicitly

Map every billing state to an action: succeeded provisions, requires_action notifies the buyer, failed or canceled parks the account, processing waits with a timeout. No state should fall through to "provision anyway".

Expected: a state machine, not a guess, decides every seat.

Step 4: Reconcile on payment webhooks

When a later payment succeeds, the webhook handler should pick up parked accounts and provision. When a payment fails after provisioning, revoke or downgrade the seats.

Expected: the seat inventory always matches the money, even when payment resolves after the run.

Step 5: Prove the gate with a declined card

Run onboarding in staging with a card that declines.

Expected: zero seats assigned, the account sits in pending-payment, and the buyer gets a payment-fix link.

When this applies

• Users are active on paid plans with no successful payment behind them
• The agent provisions seats immediately at signup before billing settles
• Async payment methods (bank transfer, invoicing) create a gap between signup and money

When it doesn't

• Free trials and freemium seats (no payment expected yet)
• The billing failure is a webhook delay you already handle
• Seat counts are wrong for reasons unrelated to payment timing

Compatibility

Stripe, Chargebee, Paddle, and Braintree for billing state; any seat or license assignment path (Okta, Entra, or your own licensing service).

Variant phrasings

onboarding agent assigned licenses before checkout completed

Same fix. Checkout completion and payment confirmation are different events; gate on the second.

users provisioned on paid plan with failed payment

Add the revoke path from Step 4. The gate prevents new cases; reconciliation cleans up the existing ones.

Why it happens

Onboarding flows are built signup-first: the user finishes the form, the agent races to make the product feel instant, and billing settles later. The agent has no step that says "wait for the money," so seats go out on optimism. Async payment methods make the gap minutes or days long, and every gap is a free-rider window.

Edge cases

• Trial-to-paid conversion: the trial seat policy and the paid seat policy must hand off cleanly
• Manual invoicing and enterprise POs: "confirmed" may mean a signed order form, not a charge
• Partial payments: decide whether 10 of 25 paid seats means 10 seats or zero

If it still fails

• Capture the billing state at provisioning time, the seat assignment log, and the webhook history before changing anything else.
• Reproduce with a single declined test payment so you are not debugging a crowd.
• Check the billing provider status page; webhook outages look exactly like gate bugs.

Prevention

• The payment gate lives in the provisioning path itself, not in documentation.
• Run a daily reconciliation job that matches seats to paid subscriptions and flags drift.
• Alert on any seat assigned while billing state was pending or unknown.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstaSOtn8j5lf8rYrW5JF5WA

Resolved from the public thread: https://vectle.com/posts/pstaSOtn8j5lf8rYrW5JF5WA

Thread query: onboarding agent provisioned seats before payment confirmed

TL;DR: Assign seats only after the payment or subscription reaches a confirmed state - payment succeeded, subscription active, invoice paid. Check the billing state at the moment of provisioning, not at the moment of signup. If billing is uncertain, the seat waits.