Onboard a new customer so the first month goes well

When to use

A contract with a new customer has just been signed. Not for a customer still deciding — use sales.follow-up-offer. Not for renewals or expanding an existing account — use sales.quarterly-account-review. Not for issuing the invoice itself — that is money.issue-invoice, which this playbook triggers but does not perform.

Before you start

• The signed contract is recorded and findable (id, date, price, scope).
• The owner (account owner at the company) is named. "The team" is not an owner.
• Billing contact details exist, or S4 will produce a task to get them — the first invoice must not wait on this.

What a run requires2

The trail8 steps

1. S1

   Read the contract backagent

   Open the signed contract and write, in five lines: what was bought, the price, the start date, the renewal date, anything promised with a date.

   Done when the five lines sit in the customer record and any date is also in the calendar.

2. S2

   Name the peopleagent

   Fill the customer record: decision maker, day-to-day contact, billing contact — name, e-mail, phone.

   Done when no field says "TBD" or points at a generic address only.

   ⛔ A generic info@ address as the only contact is how month-one questions go unanswered.

3. S3

   Agree the first monthownerneeds approval · owner

   Approval · S3 · owner — the run stops until a named person records the decision

   Draft a one-page plan: one owner, one first deliverable with a date, what is explicitly *not* in month one.

   Done when the owner has approved the plan and the first deliverable date.

   ⛔ Do not promise anything in the plan that the contract does not cover — extra promises become unpaid scope.

4. S4

   Set up access and recordsagent

   Create the accounts and access the customer needs (module: crm/admin — describe the action in the plan step), add the customer contacts to the mail module's shared contacts, create the onboarding task list with bc tasks add under the customer's goal (bc goals add if none exists), and link the contract record.

   Done when a person other than the agent can find the plan, the tasks and the contacts from the customer record alone.

5. S5

   Send the welcome packagentneeds approval · owner

   Approval · S5 · owner — the run stops until a named person records the decision

   Draft and, after the owner approves, send the welcome e-mail: who their owner is, the plan from S3, what you need from them (billing details, data, logins), and the date of the first deliverable.

   Done when the e-mail is sent from a role address and a copy is filed in the customer record.

   ⛔ Never send pricing, dates or promises to the customer before S3 is approved — the e-mail is the promise.

6. S6

   Hand over to deliveryagent

   Post the five-line summary and the approved plan to the delivery team's channel or meeting, and name who does the first deliverable.

   Done when delivery has confirmed in writing who owns the first deliverable and by when.

7. S7

   Trigger billingagent

   Check the billing contact and details from S2 are complete; if yes, hand off to money.issue-invoice per the contract's payment terms; if no, chase the billing contact and record the gap.

   Done when the invoice task exists with a due date, or the missing detail is recorded as an open task with an owner.

8. S8

   Book the day-30 check-in and watch week oneagent

   Put the 30-day check-in in the calendar with an agenda (delivered? billed? happy?). During week one, watch for customer questions and answer or route them the same day.

   Done when the check-in is booked and the week-one questions are logged.

Checks — how we know it worked

• Read the welcome e-mail back against the approved S3 plan: same deliverable, same date, nothing extra.
• The customer record shows: contacts filled, start and renewal dates, contract link, plan link.
• The invoice task has a due date matching the contract's payment terms.
• The day-30 check-in exists on a calendar, with an owner, not "sometime after launch".
• Delivery named a person, not a team, for the first deliverable.

If it goes wrong

What each step leaves behind

1. S1the five lines sit in the customer record and any date is also in the calendar.
2. S2no field says "TBD" or points at a generic address only.
3. S3the owner has approved the plan and the first deliverable date.
4. S4a person other than the agent can find the plan, the tasks and the contacts from the customer record alone.
5. S5the e-mail is sent from a role address and a copy is filed in the customer record.
6. S6delivery has confirmed in writing who owns the first deliverable and by when.
7. S7the invoice task exists with a due date, or the missing detail is recorded as an open task with an owner.
8. S8the check-in is booked and the week-one questions are logged.

Evidence to keep

Contract id and signature date · the five-line summary · the approved S3 plan (who approved, when) · the sent welcome e-mail · the invoice task id · the day-30 check-in date · scope-change requests from month one.

How this playbook improves

After every 10 onboardings ask: days from signature to first deliverable, and which step caused the wait? Did any first invoice go out late, and was S2 or S7 the cause? Did any month-one promise turn out to be outside the contract? A new version changes the step that caused the wait or the drift, and says so in its change note.