Automating client onboarding should first remove copying, not remove judgment. A form submission is a request for work, not proof that a contract is signed, a deposit has cleared or a start date is available. For a solo service business, a useful first version is deliberately small: collect an intake response, copy it into a review queue and let the owner approve the next step.
This guide describes a proposed Google Forms → Make → Google Sheets setup, based on official documentation checked October 19, 2026. It is not a hands-on case study or an imported, tested scenario. The field names, records and acceptance tests below are synthetic design examples. You do not need an AI module or a paid model API for this version.
Define the boundary before connecting accounts
The outcome is an internal onboarding queue, not an automatic customer welcome campaign. Keep payments, account provisioning, contractual promises and outbound client messages outside the scenario. A person still checks scope and availability before starting work.
You need a Google account that can manage the form and destination spreadsheet, a Make account, and a named person responsible for reviewing the queue. Confirm your organization’s permission to send this intake information through those services. Use only fictitious data during setup, inspect requested connection permissions and check the allowances in your current Make plan before scheduling runs. This article does not authorize a purchase or assume every plan has identical features.
Make documents the Google Forms connection and a Watch Responses module. Its Google Sheets integration lists Add a Row, which appends a record to a table. These are the two building blocks for the collection phase. We are not using the legacy Forms-in-Sheets trigger or a custom webhook script. Google Forms modules and connection, Google Sheets integration actions.
Create a form that asks only for the next decision
Start with contact name, business name if needed, reply email, requested service, preferred start date and a short project description. Use a defined service list rather than unrestricted product names. Label the date as a preference, not a booking confirmation. Avoid passwords, banking information, identity documents and client file uploads in this initial intake.
Explain why you are collecting the information, who will follow up and which privacy notice applies. Keep marketing consent separate from a request about a project. Do not make a promotional subscription a hidden consequence of submitting the form.
Google’s response-management guidance explains how to inspect individual submissions, link responses to Sheets and configure email collection. Check the settings actually available in your account; a typed email address is not proof that someone controls it. Restrict editor access and verify what a respondent can see after submission. Google Forms response-management guidance.
A linked response sheet is optional for this design. If you use one as a raw source archive, keep it distinct from the destination review queue. Do not let two different scenarios append the same submission into the same destination accidentally. Document where each copy lives so a later correction or removal request is not handled in just one place.
Build a review queue with a controlled approval field
Create a destination sheet called Intake Queue. Put column headers in its first row and decide which columns come from the submission versus which are controlled by your business. Here is a suggested mapping, not a vendor-required schema:
| Queue column | Source or initial value | Reason |
|---|---|---|
| intake_key | form ID plus response ID | Recognize the same submission again |
| submitted_at | Source response timestamp | Reconcile against the form |
| contact_name | Contact-name answer | Identify the enquiry |
| reply_email | Collected email or required email answer | Follow up after review |
| service_requested | Service answer | Check scope |
| preferred_start | Date answer | Check availability, not book work |
| project_summary | Short-description answer | Prepare internal review |
| review_status | Constant: needs_review | Prevent respondent-controlled approval |
| assigned_owner | Your internal default owner | Make responsibility visible |
| duplicate_of | Initially blank; owner completes if needed | Record a repeated delivery |
| approved_at | Initially blank; owner-controlled | Record the approval decision |
Google’s Forms API response resource exposes formId, responseId, timestamps and answers keyed by question ID. It includes respondentEmail only if that email was collected. Use those identifiers where your selected module exposes them; inspect an actual synthetic output bundle rather than guessing field labels. If the identifiers are not available, stop and resolve that mapping before relying on duplicate checks. Google Forms response fields.
The approval column must not come from a respondent’s answer. A person typing “approved” into the project description must not change review_status. Restrict editing of the queue to people authorized to handle enquiries, and avoid sharing the sheet through a public link.
Connect the two modules and inspect one synthetic record
Create a new scenario, add Google Forms Watch Responses and select the intended form using the authorized connection. Configure its starting point deliberately. For testing, use a dedicated test form or an explicitly selected test starting point so historical real submissions are not replayed unexpectedly.
Add Google Sheets Add a Row and select the separate destination spreadsheet and Intake Queue tab. Map the collected values into the columns above. Supply needs_review as a constant; leave approval fields blank. Do not add an email-sending module just to make the demonstration look complete.
Treat free text as text rather than spreadsheet instructions. If your module offers a value-input setting, inspect its documented behavior before choosing it. Google’s Sheets API distinguishes RAW input, stored without parsing, from USER_ENTERED input, which is interpreted as spreadsheet input. Test a harmless value such as =1+1: a project-description cell should preserve the literal text, not execute it as a formula. Do not enable real intake until that behavior is understood. Google Sheets value-input modes.
Run a synthetic response through the collection phase. Compare every destination cell with the source. Check the email mapping, date interpretation, multiline description and internal owner. Scheduling is a separate decision: choose a frequency your plan supports and that matches how often someone can actually review new requests. Do not promise customers an instant response based only on a trigger’s name.
Handle repeats and failures without pretending this is exactly-once
This simple append-to-queue design can create duplicate rows after a replay or an ambiguous failure. It does not guarantee exactly-once processing. Before approving an intake, search the queue for its intake_key and identify one canonical record. Mark a repeated row as duplicate with a reference to the original, rather than treating it as another customer request.
For a synthetic example, call the key demo-form:response-001. The first delivery creates a needs_review row. A replay may create a second row with the same key; the reviewer marks that row duplicate_of demo-form:response-001 and approves only the canonical record. A fresh submission from the same person can have a different response ID, so also review whether it is a correction or a genuinely new enquiry. Matching email alone is not enough to decide.
If the spreadsheet permission is revoked, the scenario cannot be assumed to have written a row. Inspect the source response, Make execution history and destination before retrying. A failed response from an integration can be ambiguous: the write might have completed before the acknowledgment was lost. Make provides error handlers for failure paths, but their existence does not make every retry safe. Make error-handler documentation.
Keep a manual fallback: review source responses that have no corresponding queue record. During initial operation, reconcile after each collection run; later choose and document a review frequency appropriate to the business. Do not silently discard an incomplete response. Leave it visible for a person to resolve, and never post sensitive submission details into a broadly shared error channel.
Use acceptance tests before real intake
The following is a test plan, not a report of tests we performed:
| Synthetic case | Required observation before enabling real intake |
|---|---|
| Complete response | Correct fields arrive with needs_review, owner assigned and no client message |
| Missing or unexpected email field | No approval; mismatch is visible for review rather than guessed |
| Same response replayed | Repeat key is recognized during review; only one canonical intake is approved |
| Description contains =1+1 | Literal text is preserved, not an evaluated formula |
| Destination access removed in test setup | Failure is visible; no claim that the queue is complete |
| Source field renamed or replaced | Mapping is rechecked; unrelated fields do not shift silently |
| Write outcome unclear | Source and destination are reconciled before a retry |
Record the expected result, actual result and corrective action for each case. Repeat the affected tests after field changes or connection renewal. Our workflow testing guide provides a broader way to organize that evidence.
My recommendation
Keep this internal intake version until someone can explain every row, repeat and failure. Add customer-facing automation only as a separately reviewed phase with protected approval, a send log, duplicate prevention and an explicit recovery process. A review queue is useful automation even though a person still makes the commitment.
Measure the work rather than assuming savings. As a purely hypothetical example, 30 monthly enquiries taking four minutes each to copy would consume 120 minutes. If the new process takes 45 minutes of review and 30 minutes of maintenance, the net difference is 45 minutes, not two hours. Replace every input with observed figures and deduct software costs; saved time is not automatically additional revenue.
If Make’s connection choices or maintenance burden do not fit your business, compare alternatives using our Make-versus-Zapier decision guide. The goal is reliable onboarding with less total work, not the largest possible automation.
Leave a Reply