SplitTesting / Client onboarding / System 01 of 04
2021Recorded work
Agreement and payment gates for client onboarding
Start onboarding after payment, or after a signed agreement with nothing to pay. Flag unpaid agreements for follow-up instead of treating a signature as a completed purchase.
- Noah’s contribution
- Connected document state, payment checks, client creation and onboarding communication.
- Historical stage
- Configured historical walkthroughs; related duplicate-trigger diagnosis is a separate white-label implementation.
- Part of the business
- SplitTesting overview ↗
- PandaDoc
- Zapier
- Make / Integromat
- Monday.com
- Slack
Inside this system
The workflow
The handoffs
inside the work.
Follow the main path and its branches. Select a step for context; the account below explains what was built, tested or planned.
- PandaDoc agreement event
Receive paid or signed/completed document activity. - Onboarding template matches?
Keep unrelated document events outside this onboarding workflow. - Paid, zero-total or unpaid?
Separate a paid document from a signed free agreement and a signed amount still due. - Qualifying onboarding event
Paid documents and signed zero-total agreements can start client onboarding. - Delayed payment recheck
For a signed nonzero agreement, wait fifteen minutes and retrieve its current state. - Monday client-directory item
Create the client record that subsequent intake steps can identify. - Outstanding-payment notification
Notify the team if the delayed check still finds payment outstanding. - Send client-linked intake form
Include the client identifier in the form link and record onboarding-email state. - Onboarding-channel handoff
Notify the team that the qualifying agreement has begun onboarding.
Key records
The information
that carries forward.
| Record | Information | Purpose |
|---|---|---|
| Agreement | Document identifier, onboarding template, total and payment state | Determine which event can begin onboarding. |
| Client directory item | Company context, client contact and onboarding-email status | Provide the record that later intake steps update. |
| Payment follow-up | Fresh document status after the delay | Give the team a specific unresolved payment to review. |
Inside the system / 01
A signature and a payment mean different things
The starting point was an agreement event in PandaDoc. The workflow checked whether the document belonged to the onboarding template before passing its identifier to the next scenario. Retrieving the document then supplied the information used to create the client’s onboarding context. That template check kept unrelated document activity outside this process.
The recorded configuration had two legitimate ways into onboarding: a paid document event and a signed document whose grand total was zero. Treating these separately mattered because a zero-total agreement would never generate a payment, while a signed agreement with an amount due still required collection.
Inside the system / 02
Recheck the source before raising an exception
For a signed, nonzero document, the payment-validation scenario waited fifteen minutes and retrieved the document again. The second lookup checked its current state, rather than reusing the status captured at signing. If payment remained outstanding, the workflow prepared a Slack notification using the agreement information.
The delay was a payment follow-up window. It did not turn an unpaid signature into a completed purchase or make a credit decision. A separate paid-document event supplied the normal paid route into onboarding. This distinction also made the purpose of each branch easier to explain during handover.
Inside the system / 03
Carry identity into the next step
Once a qualifying event reached the onboarding scenario, the document details created a Monday client-directory item. The onboarding email included a Typeform link carrying a custom identifier, so a later form submission could be associated with that client. The record’s email status was updated after sending, and the onboarding channel received a team notification.
A related white-label debugging recording identified duplicate onboarding caused by allowing a delayed payment check to start onboarding as well as the dedicated paid-document route. That was a separate implementation, but it illustrates the boundary being managed: two events describing the same purchase can otherwise both launch the next process. The available SplitTesting walkthroughs establish the configured branches and handoff; they do not establish complete replay protection, all refund paths or a measured onboarding improvement.
Within SplitTesting