Commercial-to-Delivery Project Handoff Automation

The core business problem

Deals get closed and nothing moves. Sales marks an opportunity Closed Won and celebrates, while delivery scrambles for a scope document, a signed agreement, or even a named project owner. Projects start with missing context, owners get decided by who is loudest in the room, and clients are invited into empty workspaces.

This system treats a closed deal and a project handoff as two separate events. A deal that goes Closed Won does not create a project. It enters Handoff Preparation, and only when every required field is validated does it become Ready for Handoff - the single state allowed to trigger project creation.

One automation spine runs three connected workflows:

1. Closed Deal → Project Board - validated handoff, template-driven project setup, gated client invitation.
2. Weekly Client Update Draft - a draft update built from real project activity, sent only after PM approval.
3. Asset Approval Routing - standardized client review with deadlines, escalation, and version control.

The tech stack

• CRM: HubSpot, Pipedrive, Salesforce, or any system with deal stages + custom fields (the source of truth for the commercial side).
• Project Management: ClickUp, Asana, monday.com, Wrike, or Notion - anything that supports folders, task templates, and custom fields.
• Automation Engine: n8n / Make / Zapier - schedules, webhooks, and the branching logic between systems.
• AI Logic Engine: Anthropic Claude / OpenAI ChatGPT / Google Gemini - for summarizing activity and drafting client updates.
• Email & Vault: your existing email provider plus a credential vault (1Password, Vaultwarden, or the automation platform's own encrypted credentials). Secrets never live in workflow logic.

The workflow logic

The system is a controlled pipeline, not a single integration. Below are the three blueprints, followed by the shared data model, audit layer, and edge cases.

Blueprint 1: Closed deal → project board

The lifecycle states

The critical gate is READY_FOR_HANDOFF. Only deals in this state can create a project - everything before it is validation.

Step 1: Trigger on closed won

The workflow fires when the CRM deal stage changes to CLOSED_WON. It does not create a project. It fetches the full deal record - account, contact, sales owner, pricing, documents, scope, dates, and custom handoff fields - and starts HANDOFF_PREPARATION.

Step 2: Find the existing client

Search by CRM account ID, company domain, email domain, or existing customer ID before creating anything. Three outcomes:

• EXISTING_CLIENT - reuse the existing client record.
• NEW_CLIENT - safe to create.
• AMBIGUOUS_MATCH - create a manual review task; never guess.

Step 3: Validate handoff fields

Check every required field across five groups - client details, commercial details, project scope, timeline, ownership, and supporting documents (signed agreement, proposal, SOW, technical requirements, design files, access docs, discovery notes). Any field can be marked required: true / false in the handoff schema, so validation adapts per organization.

If anything is missing: set HANDOFF_BLOCKED and notify the deal owner with the exact list of missing fields. Also create a handoff completion task assigned to the deal owner with a configurable deadline (default: 1 business day).

Handoff completeness score

Instead of binary validation, score readiness. Example weights:

Logic fork: completeness < 100% → remain HANDOFF_PREPARATION. Completeness = 100% → allow READY_FOR_HANDOFF.

Escalating reminders

While blocked, a scheduled check runs:

• After 4 hours - reminder to the deal owner.
• After 1 business day - notify the deal owner and the sales manager.
• After SLA breach - notify the sales manager and the delivery lead. Status stays HANDOFF_BLOCKED.

Step 4: The real project-creation trigger

Only when sales moves the deal to READY_FOR_HANDOFF does creation begin. First, prevent duplicates: look up an existing project by deal ID, client ID, external project ID, or project name + client. If one exists, set HANDOFF_DUPLICATE_DETECTED and notify operations - never recreate.

Step 5: Resolve template and owner

Resolve the project template from project type, service, package, department, or complexity (e.g. Website Development → WEBSITE_IMPLEMENTATION_TEMPLATE).

Logic fork: no template found → BLOCKED_TEMPLATE_MISSING, notify the project owner, operations, and sales owner. A GENERIC_PROJECT_TEMPLATE fallback is allowed only if explicitly configured.

Resolve the project owner from the CRM field, resource planning, service owner mapping, or team rotation.

Logic fork: no valid owner → BLOCKED_MISSING_OWNER. Stop creation, notify the sales owner, delivery manager, and operations. Never auto-assign an arbitrary person.

Step 6: Create the workspace and apply the template

Create the structure CLIENT → PROJECT → SECTIONS / PHASES → TASKS with standard phases: 01 Discovery, 02 Planning, 03 Implementation, 04 Internal Review, 05 Client Review, 06 Final Delivery, 07 Handover.

Instantiate the template into predefined tasks - discovery (review contract and scope, confirm stakeholders, review supplied materials, confirm technical access, kickoff preparation), planning (implementation plan, milestones, timeline validation, dependencies, client responsibilities), implementation, review (internal QA, client review, revision cycle), delivery (final QA, delivery confirmation, documentation), and handover.

Each generated task carries metadata: project ID, client ID, deal ID, task owner, due date, dependencies, priority, client visibility, approval requirement, phase, and SLA. Due dates are relative to the project start date (Kickoff = Start − 2 days, Discovery Complete = Start + 5 days) so templates stay reusable - never hard-code dates into templates.

Step 7: Assign the team, attach context, invite the client

Map roles (Project Manager, Designer, Developer, Automation Engineer, QA, Account Manager) to tasks so tasks inherit owners. Attach commercial context by linking the CRM deal, contract, proposal, scope, discovery notes, client folder, and technical docs - prefer links to source-of-truth systems over duplicated copies. Create the client shared space for deliverables, approval files, updates, and shared documentation.

Logic fork: verify the workspace exists, template applied, owner assigned, tasks created, and shared area ready - only then invite the primary client contact (plus optional secondary, technical, and billing contacts) and send the welcome email with project name, start date, project owner, workspace link, access instructions, and kickoff information.

Step 8: Close the loop

Send the internal notification (PROJECT_CREATED, TEMPLATE_APPLIED, TEAM_ASSIGNED, CLIENT_INVITED) to the sales owner, PM, and delivery team with project and deal links. Then update the CRM: handoff_status = HANDED_OFF, project_id, project_url, project_owner, handoff_completed_at. The commercial-to-delivery loop is now closed.

Blueprint 2: Weekly client update draft

The automation drafts - it does not send. Data flows through: Project Data → Summarize → Generate Draft → PM Review → Approve → Send.

• Frequency is stored per project (client_update_frequency: WEEKLY, BIWEEKLY, MONTHLY, MILESTONE_BASED, NONE) plus preferred_update_day and preferred_update_time.
• Scheduled trigger (e.g. every Thursday) fetches projects requiring an update, then verifies each: project active, owner exists, client contact exists, frequency matches.
• Fetch activity since the last update: completed tasks, active tasks, upcoming tasks due before the next period, blockers (BLOCKED, WAITING_CLIENT, AT_RISK), pending/completed approvals, milestones, and structured team notes.
• Normalize the raw data into sections - Completed / In Progress / Next / Blocked / Awaiting Client / Upcoming Milestones - before any model touches it.
• Generate the draft in a fixed structure: greeting, completed list, in progress, next, waiting on client, upcoming milestone, sign-off from the project owner.
• Internal review creates a task for the project owner with status UPDATE_DRAFT_READY. The PM can APPROVE, EDIT, or SKIP. On approval the update is sent and logged (update_sent_at, update_period, approved_by).

Logic forks: no meaningful activity → internal NO_UPDATE_ACTIVITY notification, never a fabricated update. No project owner → escalate MISSING_PROJECT_OWNER, no draft. No client contact → BLOCKED_CLIENT_CONTACT, notify the project owner and account manager.

Blueprint 3: Asset approval routing

Standardized states: DRAFT → INTERNAL_REVIEW → READY_FOR_CLIENT → CLIENT_REVIEW → APPROVED / CHANGES_REQUESTED / OVERDUE / CANCELLED.

• Trigger: an asset (design, copy, landing page, document, milestone, technical spec, final deliverable) enters READY_FOR_CLIENT.
• Resolve context: verify the project is active, the asset belongs to it, and a client contact plus an approval_owner exist (e.g. Design → Marketing Lead, Technical Spec → Technical Owner, Final Deliverable → Executive Sponsor). Approval owner is stored separately from client contact.
• Create the request: asset, version, project, approval owner, requested date, due date (default 3 business days), notes, and an approval link.
• Notify the client with only two unambiguous options: APPROVE or REQUEST CHANGES.
• On approval: set the asset to APPROVED and unblock dependent tasks (e.g. homepage design approved → development task unblocked).
• On changes: create a revision task for the original asset owner with the feedback, asset version, and request timestamp.
• Overdue monitoring: a scheduled check marks requests OVERDUE when due_at < now and status is CLIENT_REVIEW. Escalation steps: first reminder to the approval owner, second to owner + project manager, then escalation to owner + PM + account owner - plus a project risk flag with reason CLIENT_APPROVAL_DELAY. Optionally recalculate dependent deadlines and set the project to AT_RISK_CLIENT_DEPENDENCY before the final deadline breaks.
• Version control: every approval records asset_id, asset_version, approval_status, approved_by, approved_at. A new version resets approval.

The data models

Project

Approval

Vault architecture - credentials for the CRM, project system, email, file storage, AI provider, and document system live in the vault only. Workflows look them up at runtime. Secrets never appear in task descriptions, project comments, client emails, or audit logs.

Audit layer - every lifecycle event writes a standard log: event_id, workflow_type, deal_id, project_id, client_id, event, previous_status, new_status, executed_by, executed_at, result, error, workflow_run_id. Example events: HANDOFF_STARTED, HANDOFF_BLOCKED, HANDOFF_READY, PROJECT_CREATED, TEMPLATE_APPLIED, CLIENT_INVITED, UPDATE_DRAFT_CREATED, UPDATE_SENT, APPROVAL_REQUESTED, APPROVAL_OVERDUE, ASSET_APPROVED.

What to watch out for

Notification strategy - signal, not noise. Sales hears about incomplete handoffs, completed handoffs, and project creation. Project managers hear about assignments, setup completion, client invites, ready drafts, and overdue approvals. Clients hear about project access, required approvals, sent updates, and milestone completions. Operations hears about missing owners, missing templates, automation failures, and duplicate detections.

Business ROI

• Handoff speed - measurable Closed Won → Ready for Handoff and Ready → Project Created times replace the mystery of "how long until delivery actually starts".
• Zero incomplete projects - no project enters delivery without scope, ownership, and a template; blocked handoffs and their top missing fields are tracked, not guessed.
• Saved setup time - template instantiation, role-based task assignment, and dynamic due dates replace hours of manual project assembly.
• Client trust - updates arrive on a cadence from real activity, and every approval has a state, a deadline, an owner, and an audit trail.
• Risk visibility - overdue approvals flag project risk before the final deadline, not after.

Blueprint spec sheet

Build it step by step

Phase 1: Handoff gate

1. Watch the CRM deal for CLOSED_WON; fetch the full deal record and set HANDOFF_PREPARATION.
2. Run the client lookup (account ID, domain, email domain, existing customer ID); create a review task on AMBIGUOUS_MATCH.
3. Validate the handoff schema (each field carries required: true/false); compute the completeness score from your group weights.
4. On < 100%: notify the deal owner with the exact missing fields, create the completion task, and schedule reminders at 4 hours → 1 business day → SLA breach with widening audiences.

Phase 2: Project creation

5. Listen for READY_FOR_HANDOFF (the only creation trigger). Duplicate-check by deal ID, client ID, external ID, and name + client.
6. Resolve template and owner; block with BLOCKED_TEMPLATE_MISSING or BLOCKED_MISSING_OWNER instead of falling back silently.
7. Create the workspace (Client → Project → Phases → Tasks), instantiate the template, and write task metadata with dates computed from the project start date.
8. Map roles to tasks, attach commercial context links, and create the client shared space.
9. Verify the full structure, then invite the client, send the welcome email, notify the internal team, and set the CRM to HANDED_OFF with project references.

Phase 3: Weekly client updates

10. Store update frequency per project; run the scheduled fetch and verify project, owner, and contact before drafting.
11. Collect activity (completed / active / upcoming / blocked / awaiting client / approvals / milestones), normalize it, and generate the draft in the fixed structure.
12. Create the PM review task; on APPROVE send and log the update. Handle NO_UPDATE_ACTIVITY, MISSING_PROJECT_OWNER, and BLOCKED_CLIENT_CONTACT as internal escalations, not silent skips.

Phase 4: Asset approvals

13. On READY_FOR_CLIENT, verify project, asset ownership, client contact, and approval owner; create the request with a due date.
14. Send the client the approval link with only APPROVE / REQUEST CHANGES options.
15. On approval: set APPROVED and unblock dependents. On changes: create a revision task for the asset owner.
16. Run the overdue check; escalate in three widening steps and flag project risk. Record version, approver, and timestamp on every approval.