Lead follow-up automation: from form to CRM to a named owner

Decide what a completed handoff means

Use one small workflow first: Typeform receives an enquiry, Zapier writes it to HubSpot, and Trello holds the owner's follow-up card. The CRM keeps the contact details. The card makes the next action visible. If your CRM already gives the team an effective task queue, use that instead of adding another app.

Prepare connected test accounts, a published test form, an internal Trello board and the needed CRM properties. Confirm the chosen plans include the actions and custom fields. This example assumes one active enquiry per contact; a second distinct enquiry goes to review rather than overwriting the first. Businesses with several simultaneous opportunities should use a separate deal or enquiry record for each.

Keep RequestId, contact ID, owner ID, card ID, status, received time and next-action time. Use statuses such as New, Assigned, Replied, Booked and Closed. Agree who changes them. These six synthetic exercises show expected outcomes, not results from executed Zaps. Test with made-up records and keep external messages disabled.

Example 1: capture the enquiry before notifying anyone

Set up Typeform > New Entry in Zapier and select the specific test form. Submit a complete response with an email, service choice and short request. Inspect the returned response identifier and map it to RequestId. Do not generate a new identifier each time you retry the same response.

RequestId: FORM-201
Email: alex@beacon.example
Service: Reporting
Message: We need one weekly delivery report.
ReceivedAt: 2026-09-28T14:00:00Z

Expected: a HubSpot contact ID and the saved enquiry details
No owner card yet if the CRM save fails

Add a required-field check before the CRM action. A missing email or service should reach a review route with its RequestId. Do not create an empty contact and call the run successful. If partial form responses are enabled, decide whether they are eligible; this exercise accepts completed submissions only. The Typeform setup guide describes the trigger and partial-response requirements.

Use the available HubSpot contact action to find and update the intended contact or create a new one. Map current response fields rather than typed test values. The HubSpot integration listing identifies the available contact actions. Check the saved record in HubSpot and capture its returned ID.

Test a second address and a missing message. Confirm the second address does not overwrite Alex. Agree whether an empty optional answer should leave an existing value alone. Keep the submission's source and timestamp; they explain why this contact entered the queue.

Example 2: route an unknown service to review

Choose the owner with a small explicit rule. In Formatter by Zapier, select Utilities > Lookup Table. Map the service choice as the lookup key, then enter the approved owner IDs. Set the fallback to REVIEW instead of a real person.

Service key       Owner key
Reporting         OWNER-MAYA
App support       OWNER-LEO
Anything else     REVIEW

Input FORM-202: Service = Data migration
Expected: review queue, with no guessed owner

The owner keys above are examples. Map them to actual HubSpot user IDs and Trello member IDs in your configuration. The same person normally has different IDs in the two apps. Keep the cross-reference in a place the workflow owner can maintain. Zapier's lookup guide explains keys and fallback values.

Use Paths after the lookup. One branch handles valid owner mappings; another handles REVIEW. Make the conditions mutually exclusive. Zapier can run more than one matching branch, so “service exists” and “service is Reporting” are not safe alternatives. See the Paths rules.

Test Reporting, App support, an empty service and a new choice added to the form. Expect two assigned cases and two review cases. Change an owner's availability in the mapping and check that new requests use the replacement. This is explicit service routing, not round-robin balancing. Do not call it fair workload distribution without a separate capacity rule.

Example 3: create a card the owner can act on

After a confirmed CRM save and owner lookup, add Trello > Create Card. Select the internal test board and its New enquiries list. Map Member ID(s) from the approved owner mapping. Use the returned contact ID or record link in the description, plus the RequestId and request summary.

Card name: FORM-201 | Review reporting enquiry
Owner: Maya's Trello member ID
Due: 2026-09-29T14:00:00Z
Description: Request summary + CRM link + RequestId
Expected: one actionable card linked to the right contact

Trello's Zapier action exposes the board, list, name, description, members and due date. Set an explicit due date for the exercise. The sample is 24 elapsed hours after receipt, not a next-business-day promise. Agree a working-hours rule separately if the team needs one.

Save the returned card ID back against the active enquiry. The ID is the reference for later updates. A card title is useful to people but is a weak identifier for automation: it can be renamed or reused.

Open the card as the intended owner during your account test. Check that they can read the request and open the CRM link. A successful create action does not prove the assignee has usable access. If assignment fails, keep the item in review and record the failure. Do not silently leave it unassigned.

The completion check is specific: a CRM record, its matching card and the correct owner. A notification alone is not the next action. The owner needs to know what to do and when.

Example 4: remind the owner after checking the current status

Add a one-day Delay For after the initial handoff in a separate test branch. After the delay, use HubSpot > Get CRM Object with the saved contact ID. Retrieve the active RequestId, status and card ID again. Then filter for the same RequestId still waiting for its owner.

Delayed event: FORM-201
Current CRM: RequestId FORM-201, Status Assigned
Expected: update the existing card for owner attention

Current CRM: RequestId FORM-201, Status Replied
Expected: no overdue reminder

Current CRM: RequestId FORM-219
Expected: stop; this is a different active enquiry

Use current fields from the retrieval step in the filter. Fields carried from the original trigger describe the past. They cannot tell you that someone replied during the wait. Read Zapier's delay behavior before using delayed work in production.

For the first test, update the existing Trello card's description with an internal attention note rather than sending another customer email. Preserve the original request summary. Use the saved card ID; do not create another card for the reminder.

Try a reply just before the delayed branch resumes. Expect it to stop. If retrieving the current record fails, leave the reminder unresolved instead of treating missing data as “no reply.” A change can still happen after the fresh read; this design reduces stale reminders but does not make the read and update one atomic operation. Keep the action internal and easy for the owner to dismiss.

Example 5: stop follow-up when the person replies or books

Make status updates part of the owner's routine. In this first version, the owner records Replied, Booked or Closed in HubSpot after checking the conversation. That is more reliable than claiming reply detection exists when no mailbox integration has been built.

FORM-203: Status changes from Assigned to Booked
Saved Trello card: CARD-203
Expected: update CARD-203 to the agreed handled list
A waiting reminder later reads Booked and stops
Marketing subscription: unchanged

For the card update, create another Zap using HubSpot > New Contact Property Change for the agreed status property. Filter for the terminal statuses and a present card ID, then update that existing Trello card. Test each status and a change to an unrelated property. Use the current active RequestId to avoid closing an older or unrelated opportunity.

A request for help and a newsletter subscription are different instructions. Keep a direct response to that request separate from bulk marketing enrollment. Creating a CRM contact or owner task must not automatically subscribe the person to campaigns. HubSpot exposes marketing subscription status separately; preserve those preferences and the source of any subscription choice.

If you later automate replies or bookings, match them using a dependable conversation or booking identifier and check cancellation behavior. Do not treat every email from the same address as a reply to this enquiry. Leave uncertain matches for the owner. The expected result here is a stopped internal follow-up process, not proof that a sale happened.

Example 6: recover a saved contact with a missing card

Test the boundary between CRM save and task creation. FORM-204 reaches HubSpot successfully, but the Trello action fails because the configured list is unavailable.

RequestId: FORM-204
CRM contact: CONTACT-204, confirmed
Owner mapping: valid
Trello card: not confirmed
Handoff status: Needs repair

Expected recovery: retain CONTACT-204, finish or verify the card
Do not create another contact to restart the process

Open Zap history and inspect the action inputs and outputs. Fix the destination list or mapping in the approved setup. Check Trello for a card carrying FORM-204 before trying another create, especially if the original action timed out rather than clearly rejecting the request.

Use the documented replay mode deliberately. A whole-run replay can repeat successful work. A previous search result can also be reused on replay; search behavior is not a fresh uniqueness check. Separate search-then-create steps do not prevent two simultaneous runs from creating two cards.

For a low-volume pilot, give one person the recovery queue and avoid overlapping manual recovery attempts. Higher-volume designs need a destination-supported uniqueness or idempotency mechanism. Do not describe a searched RequestId or a “done” checkbox as a lock.

Finish only after the contact, owner and card agree. Keep the original run ID, saved destination IDs and recovery decision. The duplicate-record guide covers the lower-level retry and concurrency cases in detail.

Measure the handoff, not just the number of runs

Keep a small daily check: valid enquiries received, CRM records confirmed, cards assigned, items waiting for repair and requests still without an owner. Compare the source RequestIds with the saved work. A count can match while two records refer to the same request and another request is missing.

Run the six sample cases and record destination IDs.
Test one changed form field and one unavailable owner.
Check reply and booking statuses stop later reminders.
Check a failure stays visible until resolved.
Have a second person follow the recovery instructions.

Measure time from receipt to assignment and to the first recorded human action. Do not equate a card or sent notification with a customer response. These checks can show whether the handoff works; they do not promise conversion rates. To scope help, describe the form, CRM and missed follow-up, using a made-up example rather than customer details.

Sources

Primary documentation checked September 26, 2026. Verify current connector fields and plan requirements in your account.

Need help with this in your business?

Tell Felipe which tools you use, what keeps going wrong and what you want to improve. We can use a free 20-minute call to discuss a useful first project.

Prepare a project brief

Prefer email? felipe@getquintera.com. No booking, purchase or automatic submission.