Field guide / 01Design the conversation.
Connect the handoff.
Measure the customer action.
Blueprints, worksheets and launch checks
for a connected ManyChat system.
Start hereUse this guide for one real campaign. Bring the offer, the person responsible for marketing, and whoever owns your CRM or checkout.
| If this is true | Start here |
|---|---|
| You have demand, but people get the same link regardless of need. | Design a question that changes the next step. |
| Leads reach your team without campaign context. | Map the handoff and source fields. |
| You can count DM clicks, but not confirmed bookings or orders. | Define the outcome and its receiving system. |
| Your offer or traffic source is still untested. | Validate those before paying for a complex integration. |
This is a planning and implementation guide, not an importable ManyChat template. The examples are fictional. Platform features and permissions need checking in the account you will use.
The systemThe customer should get a useful next step. Your business should keep enough context to understand what happened.
Ad, post, story or keyword.
Keep the available source.
Deliver, ask, route.
Save the answer that matters.
CRM, email, booking or checkout.
Keep the lead and its context.
Registered, booked or paid.
Use evidence from that system.
Give them what the campaign promised. Keep questions short. Make it easy to reach a person or leave the flow.
Know which route they took, where their record lives, what was confirmed, and what still cannot be matched.
Operator evidence: ManyChat describes Agency U combining paid and organic triggers with CRM synchronization and appointments. We borrow the architecture, not its reported revenue or an implied guarantee. Read the vendor case study ↗
Worksheet / campaignWrite the campaign before you draw the flow. A different creative is not automatically a different customer journey.
What are we selling, at what price, and to whom?
What will the person expect when they reply?
Which post, ad, story or keyword starts this journey?
Which answer would change the resource, offer or handoff?
What exactly should they do next, and which tool confirms it?
What will we stop, change or invest in once results arrive?
Choose one primary outcome. “Engagement” is too broad to define a successful build.
BlueprintsThese are starting architectures. Adapt the questions, tools and timing to the offer; do not add every branch to every funnel.
Deliver the promised resource. Ask the need and timing. Offer a booking link when the answers meet your written fit criteria; route other people to useful information or a person.
Ask what they need help choosing. Answer from approved product information. Send the relevant product or checkout link. Route exceptions and uncertain answers to your team.
Give the date and topic. Route unavailable people to the next suitable option. Create the registration in the actual platform and use its approved reminder channels.
Conversation / worked exampleA fictional comment-to-DM journey for a launch consulting firm. The resource is delivered before asking sales questions.
Person comments PLAN on the launch checklist post.
“Want the launch checklist? Tap below and I’ll send it.”
Send the checklist“Here it is. It covers the offer, launch sequence and follow-up.”
Open checklist ↗
“Are you looking for ideas or help setting this up?”
Ideas for now Help with setup
“When are you planning to launch?”
This month Later Not sure
Offer a call or a useful preparation resource based on your fit rule. Ask for email only when needed and explain its use. Provide a human option.
Keep automated follow-up inside the permitted messaging window. Do not build a multi-day Instagram sales sequence on delays alone. Check current account/channel rules before launch. Messaging windows ↗
Data / field mapThis is a proposed schema, not a list of native ManyChat fields. Confirm the actual field names and available identifiers in each integration.
| Field | Example | Owner / purpose |
|---|---|---|
| campaign_key / creative_key | launch_q4 / video_b | Marketing: stable labels, not changing display names. |
| entry_point / flow_version | ig_comment_plan / v03 | Automation: trigger and approved flow version. |
| first_dm_source / latest_dm_source | launch_q4 / launch_q4 | CRM: preserve first source; update latest separately. |
| need / timing | implementation / this_month | Conversation: structured answers used for routing. |
| manychat_contact_ref / crm_contact_id | opaque refs, not public URLs | Integration: supported internal identity mapping. |
| booking_id / order_id | From the destination | Calendar/commerce: stable confirmed outcome ID. |
| outcome_at / status / value | UTC time / paid / amount + currency | Outcome system: authoritative status and money. |
| permission / match_status | purpose + timestamp / matched | CRM/backend: permission record and join quality. |
A second campaign should not silently overwrite the original source. Store separate touches if your reporting needs them.
Use “unknown” with a reason. A guessed campaign or a fuzzy identity match should not become a confirmed attribution.
ManyChat provides custom user fields; availability and destination mappings still need testing. Custom fields documentation ↗
Source / linksCreate one naming sheet for the campaign. Decide what “source” means before links and reports multiply.
https://example.com/launch?
utm_source=instagram&utm_medium=paid_social
&utm_campaign=launch_q4&utm_content=video_b| Parameter | Use in this example |
|---|---|
| utm_source | Origin platform: instagram. |
| utm_medium | Acquisition channel: paid_social. Organic entries use your agreed organic convention. |
| utm_campaign | Stable campaign label: launch_q4. |
| utm_content | Creative variant: video_b. Keep flow version separately. |
Separate acquisition from delivery. Instagram may be the acquisition source while ManyChat is the delivery tool. Do not relabel every route “ManyChat” if that hides the campaign distinction you need.
Test every redirect. Check the final landing page, the form, checkout and booking confirmation. A parameter visible on the first page can still disappear later.
Keep the CRM source separately. A tagged website visit does not guarantee the booking or order contains that campaign. Confirm the destination can receive and return a reference.
Use consistent, case-sensitive UTM values. Google campaign URL guidance ↗ Cross-domain setup and testing ↗
Measurement / event contractWrite the trigger, authority and duplicate rule for every stage. Event names below are internal examples, not automatic GA4 or Meta mappings.
| Internal event | When it is true | Proof / duplicate rule |
|---|---|---|
| dm_engaged | A qualifying interaction is recorded. | ManyChat interaction; separate total runs from unique contacts. |
| lead_upserted | The CRM has accepted the lead record. | Returned CRM ID; upsert, do not recreate on every reply. |
| destination_arrived | A permitted website visit is observed. | Site measurement; not assumed from a DM click. |
| booking_confirmed | The calendar confirms an appointment. | Booking ID; store reschedule/cancel changes separately. |
| registration_confirmed | The event platform accepts registration. | Registrant + event ID; do not count repeat retries. |
| purchase_paid | The commercial system confirms payment. | Order/transaction ID; amount and currency required. |
| refund_recorded | The commercial system records a refund. | Refund ID and original order ID; reconcile net value. |
___________________
___________________
___________________
___________________
Choose one authoritative revenue basis: paid sales, cash collected or net sales. Do not mix pipeline value with paid orders.
Attribution / reality checkUse the reports for different decisions. A source connection tells you what was observed; it does not prove what caused an additional sale.
Use GA4 campaign and session reporting. Tags, consent, redirects and session boundaries affect what is observable.
Use the CRM and outcome system. Define the join, eligible touch, reporting window and treatment of cancellations.
Use platform reports under their attribution settings. Do not add those conversions to CRM sales as if they are extra customers.
For a first implementation, agree on one rule your data can support. Example: connect a confirmed booking to the most recent recorded DM campaign within 30 days. Keep the earlier touches; label this a last-DM-touch report, not universal attribution.
Thirty days is an illustrative business choice, not a ManyChat setting or industry standard. A longer sales cycle may need another rule.
ManyChat Analytics is currently an Instagram-only, paid-plan beta with gradual access. ManyChat Pixel can supplement website tracking on paid plans, but its contact token and session behavior need testing. Neither replaces an agreed revenue ledger. Analytics ↗ Pixel ↗
Operations“Request sent” is not the same as “lead received.” A useful automation includes a way to recover when a tool is unavailable.
| Failure | Customer experience | Team response |
|---|---|---|
| CRM request times out | Keep the requested resource available. Do not claim their lead was saved. | Queue a retry; alert an owner; verify receipt before marking complete. |
| Request retries | No duplicate booking or repeated sales messages. | Use supported upserts and stable event IDs; cap retries. |
| Email is invalid | Ask for a correction once; allow a human route. | Keep status incomplete; do not invent or silently repair an address. |
| Person asks an unexpected question | Offer a person instead of looping through the same buttons. | Save the context, assign an owner and pause conflicting automation. |
| Booking tool is unavailable | Explain that booking is temporarily unavailable. | Provide a safe fallback; monitor restoration and missed requests. |
| Outcome has no source join | Service the customer normally. | Record unmatched with a reason; fix the join, do not guess credit. |
| Messaging window has closed | Do not promise an automated DM reminder. | Use a permitted, consented channel or wait for a new eligible interaction. |
Never place API secrets in customer-facing HTML or tracking links. Retry queues and identity joins need an appropriate backend or integration service.
Launch / acceptance testsUse agreed synthetic records in a test environment where available. Verify the receiving system as well as the sending one.
| Test | What must pass |
|---|---|
| Correct entry point | The intended trigger runs and the available source is captured. |
| Opening interaction | The first eligible interaction advances the flow; unopened DMs do not skip ahead. |
| Each routing branch | Every answer reaches its intended next step; “not sure” has a useful route. |
| Contact capture | Invalid details are handled; saved fields match what was entered. |
| CRM handoff | The receiving record exists with the correct context and supported identifier. |
| Return visitor | An existing contact updates correctly without destroying prior source history. |
| Destination / redirects | The landing and booking/checkout route retains required parameters or reference. |
| Confirmed action | A test booking, registration or order appears once in the authoritative system. |
| Outcome return | The result joins back to the intended lead and source, or is explicitly unmatched. |
| Retry / duplicate | A repeated event does not create a second outcome or repeated customer message. |
| Cancel / refund | The status and reporting update under the agreed rule. |
| Human takeover / timeout | Assignment, automation pause and messaging-window behavior work as intended. |
For each test, record: expected result / observed result / evidence / owner / pass or fail. A screenshot of a successful outbound call is not proof that reporting received the outcome.
Companion file: launch-checklist.csv. Add account-specific tests and block launch on unresolved critical failures.
Reporting / worked exampleFictional data for two paid creatives in one booking campaign. Same reporting period, USD, same definitions; this is not a benchmark or client result.
| Campaign cohort | Creative A | Creative B |
|---|---|---|
| Spend | $1,200 | $1,200 |
| Unique engaged DM contacts | 240 | 160 |
| Qualified contacts | 48 | 64 |
| Confirmed bookings | 24 | 32 |
| Customers confirmed in CRM | 6 | 8 |
| Paid revenue attributed by our rule | $6,000 | $8,000 |
| Cost / qualified contact | $25.00 | $18.75 |
| Cost / confirmed customer | $200 | $150 |
| Attributed paid revenue / spend | 5.0× | 6.7× |
Cost per engaged contact is $5 for A and $7.50 for B. A wins on that metric. B has lower cost per confirmed customer.
A qualification rate: 48 ÷ 240 = 20%. B: 64 ÷ 160 = 40%. Use unique engaged contacts.
If 16 customers were confirmed overall and only 14 were matched to these DM sources, match coverage is 14 ÷ 16 = 87.5%. Keep the other two unmatched.
Companion file: report-example.csv. The internal example uses last recorded DM touch within 30 days of engagement; preserve unmatched records separately.
Improve / one decision at a timeDiagnose the stage before rewriting the whole conversation. Record the version and change one meaningful variable at a time.
| What you observe | What to check first | A focused test |
|---|---|---|
| Opening DMs sent; few eligible taps | Does the first message match the content promise? | Clarify the promised resource and the tap label. |
| Many replies; few relevant leads | Is the ad attracting the right need? Is the fit rule sensible? | Test a clearer creative or one useful routing question. |
| Qualified leads; few destination arrivals | Is the next step relevant? Does the link work on phone? | Simplify the handoff message or repair the link. |
| Arrivals; few bookings or paid orders | Is the destination usable? Does its offer match the DM? | Fix the destination before adding more DM reminders. |
| Outcomes exist; reporting is missing them | Are IDs, source and status actually received? | Repair the integration; do not call it a conversion problem. |
| Bookings; few customers | Attendance, sales fit and sales process. | Review qualification and sales follow-through together. |
Free-text needs, intent categories and team summaries can be useful. Test against representative messages and record uncertain cases.
Keep prices, eligibility and commitments in approved rules. Give uncertain or sensitive conversations a human route. Start with buttons when they solve the decision.
Worksheet / build briefComplete this sheet with your team. It is useful whether you build internally, hire ChatFunnels or work with another specialist.
What is selling, and which campaign starts the conversation?
What do we deliver, ask and route? When does a human take over?
ManyChat account, CRM/email, website, calendar/checkout; who owns each?
Which fields can we preserve? Which system proves the result?
Which connections, permissions or identity joins still need review?
Critical launch tests; reporting rule; what will the results help us change?
Keep buildingA reliable funnel is a conversation, a handoff and a measurement plan that work together.
ChatFunnels designs and implements ManyChat funnels, supported lead handoffs and agreed outcome tracking in your existing tools.
Bring your completed brief or ask a question: towersjavin@gmail.com.
Sources checked 10 October 2026. The blueprints, worksheets, naming conventions and worked data are original ChatFunnels planning recommendations, not vendor defaults. Feature access and policies can change. This guide is independent of ManyChat; no affiliation or guaranteed performance is implied.