playbook · operations
Turn client intake into a reviewed CRM record
Plan a reviewed client-intake workflow with a field map, stable duplicate key, approval boundary, test matrix, and recovery before creating CRM records.
Outcome
Turn an eligible intake submission into a field proposal that a person reviews before a CRM record is created. A CRM is the system holding customer or prospect records. This illustrative workflow uses synthetic inputs, a dedicated review queue, and a test destination. It does not send messages or make service commitments.
Fit and no-fit
Use this pattern when intake arrives repeatedly and the business has agreed field definitions. Keep unclear identity matches, conflicting records, unsupported services, and missing required information with a person. If a form already provides validated structured fields, ordinary automation may be enough; do not add a model just to copy them.
Do not connect live intake without approved access, a reviewer, duplicate controls, and a recovery procedure.
Establish a baseline
During a period chosen by the process owner, record eligible submissions, manual field-entry minutes, checking minutes, corrections, duplicates, and exceptions. Count a submission once even when it is retried. Preserve the same eligibility definition during the trial so the comparison is meaningful.
Prerequisites and field map
Prepare a synthetic intake sheet, a separate review sheet, approved service categories, a durable action ledger, and HubSpot test records or an appropriate test environment verified in your account. Do not assume every account has the same test facilities. Name an owner and backup.
| Source field | Proposed field | Validation and authority |
|---|---|---|
intake_id | External submission reference | Required stable identifier; never generated by the model. |
name | Contact name | Preserve source; reviewer resolves ambiguity. |
email | Contact email | Validate syntax and identity; model cannot infer a new address. |
request_text | Request summary | Supported only by source text; no added promises. |
service | Service category | Must belong to the owner-approved list or be flagged unknown. |
| Source version | Review version | Changes invalidate approval. |
| Reviewer decision | Approval record | Set only by an authorized person outside model output. |
Synthetic example: I17 requests a discussion of onboarding. The proposal contains the original name and test address, category onboarding, and summary “Requests an onboarding discussion.” It must not become “Agreed to purchase onboarding.”
Process map
Synthetic intake → validate fields → claim stable action key → extract supported proposal → review queue → version-bound approval → recheck destination and action state → create one test record → record destination ID.
Missing information branches to an exception queue. Rejection or expiry ends without creating. A possibly accepted write with a lost response branches to reconciliation. This sentence is the text equivalent of the process map.
Implementation options and walkthrough
Trial field mapping manually first. Use fixed rules for already structured fields and a bounded model step only where interpreting request text is necessary. The model proposes fields; it cannot select credentials, set approval, or choose an arbitrary destination.
Follow the illustrative n8n intake walkthrough for the specified Google Sheets → n8n Cloud → review → HubSpot test pattern. Verify against the live tool before acting; no execution result is claimed here. The approval-gate extension specifies stale decisions and replay handling.
Test matrix
| Case | Required expected behavior |
|---|---|
| Valid submission | Supported proposal; one test record only after authorized review. |
| Missing required field | Visible exception; no record creation. |
| Duplicate event | Same action key produces no additional record, including replay after success. |
| Ambiguous identity or service | Human resolution; no guessed merge or category. |
| Malicious instruction in request | Treated as data; no extra access, destination change, or approval. |
| Unavailable dependency | Bounded failure handling; uncertain writes reconciled before replay. |
| Denied permission | Stop visibly; no use of broader credentials as a workaround. |
| Approval withheld | No record creation; pending, rejected, and expired states remain non-executable. |
Record input, expected and observed behavior, severity, correction, and rerun result for each case. Add simultaneous duplicate and post-approval edit tests before considering live use.
Operation and fallback
Pause intake processing when writes are uncertain or approval controls fail. Assign new submissions to the existing manual process and mark their action keys so a later replay cannot create them again. Recover by comparing ledger and destination records, not by clearing the ledger.
An atomic claim or verified destination uniqueness mechanism must prevent simultaneous creates. A separate sheet lookup and append is insufficient evidence. If the chosen tools cannot enforce the needed boundary, keep the workflow as a draft-only review aid.
Measurement
Track total handling, review, correction, and maintenance minutes, actual charges, duplicate effects, and exception volume. Do not count a pending proposal as a completed CRM record. Continue only when acceptance passes and the owner can sustain review and recovery.
Sources and scope
This is an original illustrative playbook with synthetic field values. It reports no successful integration or measured results. See how we test.
Next step
Prepare the workflow brief and then inspect the n8n intake walkthrough. Suggest a correction.
Change notes
Foundation draft prepared October 20, 2026. No public publication or successful live-tool test is claimed.
Next learning step: One-page workflow brief
Related resources
Need help adapting this to your systems? Read the proposed scopes for implementation help. Availability is pending confirmation.