How to Build a ManyChat Chatbot with Make.com

Decide what the chatbot must accomplish

Start with one narrowly defined job rather than building a general-purpose bot. Useful examples include checking an order, qualifying a lead, collecting an enquiry, confirming an appointment request, or retrieving a product detail.

Write the workflow as a simple sequence:

1. Conversation input: what the person selects or types in Messenger.
2. Business action: what Make.com must find, calculate, create, or update.
3. Business outcome: what the user should be told or what internal team should be notified.
4. Exception path: what happens when the input is invalid, the record does not exist, or the connected service is unavailable.

This decision prevents a common design problem: adding modules before anyone has agreed what a successful interaction means. For example, an order lookup is not complete merely because a webhook received an order number. It is complete when the system can identify the order, determine the permitted response, display a clear status, and record or route exceptions where necessary.

Choose the data contract between ManyChat and Make.com

The connection between the tools works best when both sides agree on a small, explicit data contract. Decide which values ManyChat sends, how they are named, and what Make.com returns or triggers next.

For an order lookup, the request might contain an order number, the Messenger user identifier, and the selected request type. Make.com may need to return an order status, an estimated date, a not-found outcome, or a message asking for corrected information.

Use stable field names and avoid sending unnecessary conversation data. A compact request is easier to test, map, secure, and troubleshoot. It also makes the scenario less dependent on the wording or layout of the ManyChat flow.

Keep personal and operational data separated where possible. Only pass the fields required for the job, and decide which system should be treated as the source of truth before building the scenario.

Build the ManyChat conversation flow

Capture a specific input

Create a flow that gives the user a clear entry point, such as a keyword, menu option, or button. Explain what the chatbot can do and ask one focused question at a time.

Use a ManyChat User Input step to collect the value needed by Make.com. Save it to a custom user field with a descriptive name, such as order_number or enquiry_email. The field should represent a meaningful value, not a temporary instruction such as “answer 1.”

1. Open the relevant automation flow in ManyChat.
2. Add the starting trigger or menu action.
3. Add a User Input step with clear instructions.
4. Choose an input type appropriate to the expected answer.
5. Save the response to a custom field.
6. Add a confirmation or correction path before sending the request.

Do not assume that users will always provide perfectly formatted information. Add basic guidance for common mistakes and define what the flow should do when a value is blank or unusable.

Send the request to Make.com

In Make.com, create a new scenario and add a Webhooks custom webhook as the trigger. Copy the generated webhook URL and configure the ManyChat action that sends an external HTTP request.

Map the required ManyChat fields into the request. Depending on the available ManyChat features and the chosen response design, the request may use a JSON body or mapped parameters. The key requirement is consistency: field names in the request must match the fields you expect to inspect in Make.com.

1. Create the custom webhook in the Make.com scenario.
2. Copy its URL into the ManyChat external request action.
3. Use the POST method when sending a request body.
4. Map the custom fields and any required user or flow identifiers.
5. Publish or enable the relevant ManyChat flow for testing.

Configure Make.com to process the request

Capture and inspect a real test payload

Open the Make.com scenario and use the webhook module’s test mode, such as Run once, before sending a test interaction from Messenger. Walk through the ManyChat flow and submit a realistic value.

Inspect the received bundle and verify that each required field is present, named correctly, and stored in the expected format. Test both ordinary values and edge cases. An order number containing spaces, an email address with unexpected capitalization, or an empty answer can expose mapping problems before users encounter them.

Add validation before the lookup

Validation should happen before Make.com searches a CRM, spreadsheet, commerce platform, or other data source. Check that required values exist and apply simple normalization where appropriate. For example, remove accidental spaces from an identifier or standardize an email address before using it as a search value.

Then add the module that performs the business action. This could be a CRM search, a record lookup, a database query, or an update to an internal system. Use filters or routers to separate meaningful outcomes such as record found, record not found, invalid input, and service error.

Each branch should have a deliberate result. A missing record should not silently become a generic success message. If an internal team needs to review the case, create an operational handoff with enough context for that team to act.

Return a useful response to ManyChat

There are two common response designs. In a synchronous design, Make.com prepares structured output during the request and ManyChat uses that output in the next message, where the available features support this pattern. In an asynchronous design, Make.com completes the work and triggers a separate ManyChat update or follow-up message through the supported connection.

Choose the pattern based on the operation. A fast status lookup may be suitable for an immediate reply. A longer process, such as a multi-system check or internal approval, should usually acknowledge the request and provide a later update rather than making the user wait for an uncertain response.

Keep the result structured. Rather than returning one long sentence, define outcome fields such as:

• outcome: found, not_found, invalid_input, or error
• status: the business status that can safely be shown
• message: user-facing explanation
• next_action: what the user or team should do next

Map these values into ManyChat message blocks or the relevant follow-up action. Avoid exposing internal error messages, raw database fields, or information the user is not authorized to see.

Design failure handling and ownership

A chatbot needs more than a success path. Define what happens if the webhook is not reached, the connected service returns no record, the data is incomplete, or the scenario fails after making an update.

Assign ownership for exceptions. If a failed lookup creates a support task, the task should have a named destination, a useful summary, and a clear status. This is where a chatbot becomes part of an operating process rather than an isolated front-end experiment.

If the workflow writes leads or enquiries into a CRM, define who reviews them and when. ConsultEvo’s CRM consulting services can be relevant when the chatbot needs to fit into lead management, pipeline stages, ownership, and reporting rather than simply create new records.

Test the complete workflow before expanding it

Test from the user’s perspective and inspect the automation from Make.com’s execution history. A successful test should confirm not only that the scenario runs, but also that the right message appears for each business outcome.

1. Test the normal success path.
2. Test blank and incorrectly formatted inputs.
3. Test a value that has no matching record.
4. Test a value that could match more than one record.
5. Test the response shown when a connected service is unavailable.
6. Confirm that sensitive fields are not exposed in Messenger.
7. Confirm that any internal task or CRM record has the correct owner.

Review the scenario after real usage begins. Look for repeated failed inputs, abandoned steps, duplicate records, and branches that require manual correction. These signals often indicate a process or data-quality issue, not merely a copywriting issue.

As the workflow grows, document the trigger, required fields, connected systems, branches, response format, and owner. More modules do not automatically create a better chatbot. A smaller scenario with clear logic is usually easier to maintain than a large scenario that tries to cover every possible request.

Connect the chatbot to the wider operating system

ManyChat and Make.com are useful when they are connected to a defined business process. The next question is not whether another integration can be added, but whether the addition improves ownership, data quality, response time, or visibility.

For example, a lead capture chatbot may need to create a CRM record, assign an owner, apply a meaningful lifecycle state, and alert a team only when a decision is required. A service chatbot may need to retrieve a status while leaving the authoritative record in the service platform.

For broader workflow architecture, automation, CRM, and reporting work, ConsultEvo provides systems and automation implementation services. A relevant operational pattern can also be reviewed in the commerce and operations intelligence platform example, which illustrates why connected data and clear business access matter beyond any single automation.