Opening your saved workspace. Public pages remain available below.

All Plays
Agencies and service teams / Intermediate

A clean client onboarding handoff

Turn an intake into a reviewable project pack.

Start this Play →
WHAT YOU WILL MAKE

A validated intake table, project checklist, two email drafts, and a risk digest outline.

A project owner whose client details, kickoff tasks, and handoffs live in separate places.

Estimated effort
60–90 min sample exercise
Cost / access
Free sample / tool costs vary
First move
Check the three fictional intake rows: accept one, hold the duplicate, and return the missing-field case.
Prerequisites, inputs & cost details

Before you begin

  • An onboarding owner and agreed required fields
  • For a real pilot: authorized Google Sheets/Gmail access and an integration feasibility review

Inputs you need

  • Intake with client/project IDs and owner
  • Existing-client rows and kickoff rules

The local exercise needs no accounts. n8n hosting, Google account limits, and any AI usage must be checked before a real pilot.

YOUR PLAY WORKSPACE

Make it your next small win.

My saved work

Write a brief, practice the workflow, and keep your notes. This workspace saves your planning; it does not run tools or send anything.

See the fictional sample

Fictional agency intake; .invalid addresses cannot receive mail. No webhook or spreadsheet is connected.

intake_id,client_id,project_id,name,email,kickoff,owner,existing_active
INT-01,CL-01,PR-01,Cedar Studio,cedar@example.invalid,2026-11-10,Project owner,false
INT-02,CL-01,PR-02,Cedar Studio,cedar@example.invalid,2026-11-05,Project owner,true
INT-03,CL-03,PR-03,Harbor Sample,,2026-11-03,,false
Config: default kickoff lead time = 5 days; rush intake requires owner review.

Review a fictional intake batch as of 2026-11-01. INT-01 can become a proposed project; INT-02 is an active duplicate and must be held; INT-03 lacks required email and owner fields. Draft Clients, Projects, and Onboarding Checklist rows plus welcome/handoff emails for INT-01 only. Describe Config and Risk Log tabs, and produce a draft risk digest. Do not send or connect anything.

  1. Validate and normalize intakeTreat the fixture as webhook input. Check required fields, normalize email, and verify client/project IDs. Return missing fields without creating records.
  2. Review duplicatesCompare normalized client identifiers with the active-client list. Keep INT-02 in a duplicate-review queue.
  3. Prepare the project recordsDraft Clients, Projects, and Onboarding Checklist rows linked by IDs; describe Config defaults and Risk Log entries.
  4. Write the two draftsPrepare a client welcome and an internal handoff with the next action, owner, and kickoff target. Leave recipients unapproved.
  5. Review the risk digestList missing data, duplicate holds, rush kickoffs, and overdue items. Add a run ID so repeats can be reconciled.

Review before a real build.

  • Stop on missing required fields, ambiguous IDs, active duplicates, unauthorized recipients, or uncertain data permissions.
  • Keep welcome, handoff, risk alerts, and daily digests in draft. A named owner approves each recipient and message before any real send.
  • Use a unique intake/run ID and reconcile partial failures before retrying. This workspace does not receive webhooks, write sheets, or send Gmail.
Measures to consider
  • Count valid intake rows, duplicate holds, and missing-field holds separately.
  • Measure intake-to-reviewed-handoff time and unresolved kickoff tasks in a later authorized pilot.
  • Rerun the same intake and check that no duplicate project or email draft is created.

Primary source checked · Source review 2026-11-01. The n8n template describes intake validation, duplicate checks, sheet records, Gmail messages, and a risk digest. This adaptation keeps messages as human-reviewed drafts. It is not a deployed integration, case study, or proof of demand or earnings.

Understand the approach.

A new client should have one project record, one owner, and a clear next step.

01

The outcome

+
  • Produce one complete, reviewable onboarding pack from an intake without silently dropping missing fields.
02

Who this is for

+
  • Small agencies and service businesses with a documented intake and a project owner.
03

Validate before building

+
  • Confirm the handoff problem with one real example before building. Check native CRM/project features first.
  • Agree required fields, authorized recipients, duplicate identity rules, access, and retention.
04

Build the smallest useful version

+
  • The source pattern receives a webhook, validates and assigns IDs, then checks Clients and Config rows before producing linked records.
  • Use Clients, Projects, Onboarding Checklist, Onboarding Config, and Onboarding Risk Log tabs in an authorized test sheet. Adapt outbound steps to drafts and an approval log.
05

Deliver and operate

+
  • Give the owner accepted/held counts, the draft project pack, and a digest of missing information or kickoff risks.
  • Test repeated intake and a partial failure using sample data before asking for a live pilot.
06

Limits and things to check

+
  • Template availability does not establish demand or prove that your account permissions and schema fit.
  • Do not use the source’s automatic sends unchanged. Review recipients, content, and approval records first.

Tools and supporting resources

Source recommendations; check current access, costs, API availability, and setup in the linked documentation. No integration is installed by opening this guide.

Plan your version.

Read the planning prompt

Using the fictional intake fixture or data I am authorized to use, validate required fields and client/project IDs, hold active duplicates, and draft a Clients/Projects/Onboarding Checklist pack. Define Config and Risk Log records. Prepare welcome, handoff, and risk-digest drafts with a named reviewer. Test a repeated intake and a partial failure. Do not connect accounts, write live records, send messages, or spend money until I approve. Report missing fields, permissions, cost assumptions, and source limitations. This exercise does not prove customer demand.

Explore another Play