How to Build an AI Data Classifier in Make.com

What an AI data classifier in Make.com should do

A classifier has one focused job: inspect unstructured input and assign structured values that a workflow can trust enough to use. For example, a message might become:

• category: support, sales or feedback
• priority: low, medium or high
• customer_email: an extracted email address or null
• order_id: an identified order reference or null
• summary: a short description for a human or another system
• confidence: a defined value that can trigger review when appropriate

The output is useful only if each field has a known meaning. A category should determine a real workflow path, while a priority value should correspond to an agreed response or ownership rule. If nobody knows what happens when the model returns high priority, adding that field creates the appearance of control without improving operations.

Design the business decision before the Make.com scenario

Start with the business state you need to identify, not the AI module you want to configure. Ask four questions:

1. What kind of input will arrive?
2. Which decisions must be made from that input?
3. Which values are allowed for each decision?
4. What should happen when the text is incomplete, ambiguous or outside the known categories?

For example, a support workflow may need to distinguish a billing issue from a technical issue, identify whether an order number is present and flag messages that require human review. That is a narrower and more testable requirement than asking an AI agent to understand every customer message.

Separate classification from action. The model can identify a category, but Make.com should apply the routing rule. This keeps the workflow inspectable and makes it easier to change a destination without rewriting the prompt.

A practical architecture for AI classification

A dependable scenario normally follows this sequence:

This separation gives each stage a clear responsibility. If a route is wrong, you can determine whether the issue came from the source text, the prompt, the parsed response or the filter condition.

Build the webhook and input contract

Create a new Make.com scenario with a custom webhook when another application needs to submit text. Define an input contract before testing. At minimum, decide which fields the webhook should receive, such as message, source, record_id and received_at.

Use a stable field name for the text being classified. If one source sends content and another sends message, normalize those inputs before the AI step or create separate mappings. Include a record identifier where possible so that a classification can be connected to the original item and reviewed later.

Do not pass an entire payload to the model simply because it is available. Send the content required for the decision and retain relevant metadata separately. This makes prompts easier to test and reduces the risk of exposing unnecessary information to an external AI provider.

Define a constrained classification schema

The schema is the agreement between the AI step and the rest of the scenario. Define allowed values rather than asking for open-ended labels. For example:

• category: one of support, sales, feedback or other
• priority: one of low, medium or high
• needs_human_review: true or false
• entities: an object containing order_id, email and product, using null when absent
• summary: a short plain-text summary

Explain each category with a short definition and include an other value for cases that do not fit. Tell the model what to do when evidence is missing. A null value is usually safer than a guessed identifier, while a review flag is safer than silently routing an ambiguous request.

In the AI module, place stable instructions in the system message and map the webhook text into the user message. Instruct the model to return JSON only, use the exact keys, follow the allowed values and avoid adding commentary. Where the selected AI integration supports structured output controls, use them. The scenario should still validate the result rather than assuming that a model response is always usable.

Parse, validate and route the result

AI output often arrives as text, even when the intended result is JSON. Add a JSON parsing step after the AI module and use a representative sample to establish the data structure. Map the parsed fields into later modules only after confirming that the response contains the expected keys.

Validation should check more than whether the JSON can be parsed. Check that category and priority are among the allowed values, that required fields exist and that extracted identifiers have the expected basic format. If validation fails, send the item to a review path or record the failure with enough context to investigate it.

Use routers and filters for actions that have a clear operational meaning. A sales category might create or update a CRM record, while a support category might create a ticket or assign an owner. If the classification only changes a label and no one uses that label, it is probably not yet a meaningful automation.

When classification feeds customer or pipeline records, define how duplicate messages, existing records and ownership conflicts are handled. A classifier should not create duplicate CRM records merely because two messages contain the same email address.

For broader workflow design and system integration, the ConsultEvo systems and automation services cover the process and architecture decisions around tools such as Make.com.

Test the classifier as a decision system

Do not test only clean examples. Create a small test set containing clear inputs, borderline cases, missing information, multiple possible categories, irrelevant content and messages that should go to human review.

1. Send each sample through the webhook.
2. Inspect the raw AI response and the parsed result.
3. Compare the output with the agreed business definition.
4. Check the router, destination and assigned owner.
5. Record failures and refine one rule at a time.

Keep the test inputs and expected outcomes somewhere the team can revisit. Prompts, categories and downstream routes are part of the workflow design, not disposable configuration. If a category is frequently disputed, the problem may be the business definition rather than the model.

Example: routing inbound sales and support messages

Imagine a company receives messages through one shared form. A message asking about implementation belongs to sales, a request about an existing invoice belongs to support and a general product suggestion belongs to feedback. The classifier returns a category, extracts an email if present and marks the message for review when the category is unclear.

Make.com can then apply separate routes. Sales messages can be mapped to the appropriate CRM pipeline, support messages can be assigned to the support queue and feedback can be stored for later analysis. A message with no reliable category should go to a human owner rather than being sent to a random destination.

This example is hypothetical. Its purpose is to show the operating model: the AI identifies a bounded business state, while the automation enforces ownership and next steps. If the organization later changes its pipeline or support process, the routing logic can change independently of the classification prompt.

Common design mistakes to avoid

Using vague categories

Labels such as urgent, important or other are not useful unless the team agrees what evidence qualifies for each one. Write definitions that another person could apply consistently.

Letting the model invent new values

Open-ended labels make filters brittle and reporting unreliable. Use a fixed list with an explicit fallback value.

Routing directly from unvalidated text

Never assume that a response that looks like JSON is valid for the workflow. Parse it, check its values and handle failure before routing.

Adding AI where a deterministic rule is enough

If the source already contains a reliable status or structured field, use that field. AI is most useful where interpretation is genuinely required.

Tracking output without tracking ownership

A classified record still needs a responsible person or queue. Classification without ownership creates cleaner-looking data but not necessarily better execution.

Connecting classification to wider business systems

Once the classifier is reliable, connect it to the system where the decision has operational value. That may be a CRM, help desk, database, reporting layer or team notification. The destination should be selected based on the process, not because it happens to be the easiest module to add.

For workflows involving leads, contacts and pipeline ownership, review the surrounding CRM architecture and automation so the classified data supports a clear sales or service process. For examples of connected automation, data and operational systems, you can also review the ConsultEvo client work portfolio.

The next improvement may not be another AI call. It could be a better input form, a clearer category definition, a duplicate check, a failed-run alert or a report that shows how many items require human review. Process quality usually improves when these fundamentals are addressed before adding more tools.