Client onboarding and fulfillment

Apply ../00-lead-generation-guardrails/SKILL.md first. Every step this skill defines must still resolve channel, relationship, and jurisdiction against that skill's compliance matrix before touching a real recipient, list, or send — a client-supplied answer never substitutes for that check, it only supplies the values the check and the downstream chain then run against.

What this skill covers and where it starts

This skill starts once skill 07's proposal call has closed — a signed deal, with an explicit qualified-lead definition already agreed on that call. It covers two things: the onboarding form that turns a signed client into the concrete inputs skills 03 and 05 need, and fulfillment/reporting — running the engagement against those inputs and reporting progress against the agreed definition. Out of scope: lead-delivery-to-client mechanics — the per-lead handoff itself (a CRM sync, a Slack notification, a manual booking) — which is skill 09's job, not this one's. This skill ends once a lead is ready to deliver; it does not deliver it.

This skill declares no capability abstraction of its own. It consumes skill 03's list-building filters and skill 05's copy variables by populating them from client answers instead of agency research — the chain and the copy anatomy themselves are unchanged; only the origin of the values changes, exactly as skill 03's own text already anticipates for "the client-onboarding-driven variant."

Create vs. import: don't force a from-scratch rebuild

Mirror the create-vs-import split this pack's sibling packs use for onboarding (e.g. video-production-skills' character-identity onboarding): a client who already has a working asset should have that asset imported and verified, never discarded and rebuilt from scratch for the sake of a clean-looking intake. Ask about each of the following explicitly, before assuming a from-scratch build:

• Existing sending domain/mailboxes. If the client reports an existing sending domain and mailboxes, do not skip skill 04's provisioning workflow — skill 04 has no separate import branch; it runs the same registrar → mailbox-provider → sequencing-platform chain whether the domain is new or client-supplied, and two of its hard rules apply here exactly as they would to a freshly registered domain. First, the domain must be a secondary domain that does not share reputation with the client's own primary/brand domain — a client's "existing warmed-up domain" is very often that primary domain, which is precisely the reputation-shared case skill 04's scope section prohibits regardless of how warm it is; ask which domain this is and reject one that shares reputation with the client's identity domain. Second, "already warmed up" as reported on an intake form is self-declared status, and skill 04's warm-up gate fails closed on exactly that evidence — it requires the sending platform's own per-mailbox warm-up status, never inferred from elapsed time or asserted by anyone outside the platform. Record the client's claim, then route the domain and mailboxes through skill 04's step 3 (connect to the sequencing platform) so warm-up status is read from the platform itself before any mailbox is treated as cleared to send. If no domain exists yet, skill 04's standard workflow runs as normal. (This asset and its downstream skill are outside this skill's 03/05 field-parity requirement below — it is recorded here only to route correctly.)
• Existing lead list. If the client already has a lead list they want worked (their own CRM export, a prior agency's list, a purchased list), don't treat it as pre-built and route it around skill 03's chain — skill 03's own text states the chain (jurisdiction gate, contact_search, bulk_export, email_verification) "runs identically" whether its filters come from client intake or agency research, and skill 03 has no separate import branch to route into. Feed the client-supplied list into skill 03's Step 0 and the full chain as a client-supplied input, calling out explicitly the three gates a purchased or inherited list is most likely to fail: (1) jurisdiction reconciliation — check every row's actual jurisdiction against Step 0's cleared set, since an inherited list has no provider geography-filtered query behind it at all; (2) data-provenance — every record must still trace to "a specific provider, a specific query/filter set, and a specific date the record was pulled or last verified" per skill 03; a client-supplied list with no such trail fails this gate and must be flagged, not silently accepted; (3) the phone/TCPA carve-out — a client CRM export very often carries phone/mobile fields, and skill 03 requires those get their own TCPA resolution rather than riding through under the email-channel clearance. A client-supplied list is not pre-cleared by virtue of being client-supplied; it is untrusted input like any other list until it clears all of skill 03's gates. If no usable list exists, skill 03's standard chain runs against agency-researched filters instead.
• Existing CRM or notification channel. If the client already runs a CRM or a channel (Slack, email, a ticketing tool) they want leads delivered into, record it for skill 09 to use — this skill does not build or configure that integration itself, it only captures which one exists so skill 09 doesn't ask the client twice. (Outside this skill's 03/05 field-parity requirement below, for the same reason as the sending domain.)

State explicitly, for each of the three assets above, whether this intake found an existing asset to import or confirmed a from-scratch build is needed — a form that silently assumes "new" without asking is the design defect this section exists to prevent.