Build an AI Support Request Router

Build a webhook that uses AI to route support requests as structured JSON.

Introduction

30 Second Summary

Customer support messages rarely arrive in tidy categories. Someone has to read each one before choosing the right team or spotting a problem that needs attention now.

In this project, you will build an AI support request router with Make. The router turns a customer message into consistent routing data that another app can use.

What You'll Build

You will watch a billing message sent from Postman come back as clean JSON with a complete routing decision.

By the end of this project, you'll have:

A visible handoff from a synthetic support request to your webhook inbox in Make.
A Make AI Agent (New) workflow that classifies each message using your department rules and urgency policy.
A reusable JSON response with separate fields for department, urgency, summary, and reason.
Secret Mission: Split urgent requests into Human Review while routine requests enter Standard Support.

Are there any prerequisites?

You only need a Mac with Safari.

The first step guides you through creating free Make and Postman accounts.

Before We Start

This is your moment to commit to a concrete outcome before any hands-on work begins. Your goal is a reusable routing decision with department and urgency fields, produced from a JSON support request by AI.

Set Up Your Browser Tools

Your support router needs a place to build the workflow. It also needs a safe way to imitate the outside application that submits requests.

Make provides the visual workspace for your automation. Postman will send an HTTP request to test that your browser tools can communicate with an external server.

Both tools run inside Safari. Your workspace stays browser-based from start to finish.

Why use browser tools?

A terminal client can send an API request. Postman gives you a visible place to build the request and inspect the response.

Make keeps your attention on triggers and routing decisions. You can learn the automation pattern without setting up local developer tools.

In this step, get ready to:

Create free accounts for both browser tools.
Open Make's Scenario Builder.
Verify Postman with a test request to an echo server.

Create your Make account

A Make account gives you access to the Scenario Builder where your support router takes shape. The builder connects each trigger and decision as a visual workflow.

You can stay on Make's Free plan for this project. No paid subscription is needed for this setup.

Click Safari in your Mac's Dock.
Visit the Make sign-up page.

You should see the available sign-up methods on Make's account page.

Select the sign-up method you prefer.
Complete the account prompts shown for that method.

You should arrive at Make's signed-in workspace. Your automation workspace is now ready for its first scenario.

Click Create scenario at the top of Make.

You should see the Scenario Builder workspace. This confirms that your Make account can access the tool used throughout the project.

Having trouble reaching Scenario Builder?

Refresh the Make sign-up page if it stops loading.
Finish the provider's sign-in prompts in any extra browser window.
Return to the original Make tab after the provider confirms access.

Help me finish Make account setup. You can also compare solutions in the Make Community.

Create your Postman web account

Postman's Free plan includes its browser API client. You can prepare requests and inspect server responses without installing the desktop application.

Click the plus icon in Safari's tab bar to open a new tab.
Visit the Postman downloads page.

You should see an option for using Postman directly on the web.

Select Postman on the web.
Create a free account with your preferred sign-in method.

You should see the signed-in Postman API client inside Safari. That is your second browser workspace ready.

Keep the browser-based Postman client open for the test request.

Postman web client not loading?

Reload the Postman page in Safari.
Finish any remaining account prompts in the current browser tab.
Return to Postman on the web after the account confirms your sign-in.

Help me access Postman on the web. You can also find the current help channel through the Postman Community update.

Send a test GET request

A GET request asks a server for information without sending a request body. This quick test checks that Postman can reach an external server from your browser.

Select HTTP in the Postman API client.

You should see a new request with a method selector and a request URL field.

Keep the request method set to GET.
Enter https://postman-echo.com/get in the request URL field.

Before you send the request, what information do you expect the echo server to return?

Click Send.
Inspect the Response pane below the request.

You should see data returned by the echo server in the Response pane. This proves that Postman successfully sent the request from Safari.

Your browser test worked. Postman can now imitate the outside application that submits requests to your router.

What did the echo test prove?

The echo endpoint returns details about the request it received. It gives you a predictable server for testing the Postman client.

The visible response confirms that your method and URL reached the server. Your browser-based request workflow is ready.

✔️ The Response pane displays data

Great. Your browser-based Postman request used GET with https://postman-echo.com/get. The Response pane displayed the echo server response.

ⓧ I'd like to double check the request

Confirm the request method is GET.
Confirm the request URL is https://postman-echo.com/get.
Click Send again.
Inspect the Response pane for data from the echo server.

Response pane still empty?

Check that the method remains set to GET.
Check the URL for missing characters.
Reload the Postman web client before sending the request again.

Help me troubleshoot this Postman request. You can also review similar browser-client questions through the Postman Community update.

Your zero-install workspace is ready. Next up, you will give the automation a webhook inbox that can receive its first support request.

Create Your Webhook Inbox

Your Make workspace is ready for an automation. You already proved that Postman can send an HTTP request.

A webhook gives the automation a public inbox. Each JSON request becomes data that later modules can use.

In this step, get ready to:

Create the Support Request Router scenario.
Add the Support Request Inbox custom webhook trigger.
Capture a sample JSON request from Postman.

Build the webhook inbox

A Make scenario is the canvas that holds your automation. Its first module is the trigger that waits for each support request.

Return to Make's Scenario Builder in Safari.
Click Create scenario at the top of the page.

You will see a blank scenario canvas. The large plus button is where you add its first module.

Select the scenario name at the top-left of the canvas.
Enter Support Request Router as the scenario name.

The name at the top of the canvas now identifies this automation as Support Request Router.

Click the large plus button on the blank canvas.
Search for Webhooks in the app picker.

The app picker now shows Webhooks as a matching service.

Select Webhooks.
Select Custom webhook as the trigger.

The Custom webhook panel opens with a Webhook field for your new inbox.

Click Add in the Webhook field.
Enter Support Request Inbox in the Webhook name field.

This name identifies the trigger that receives every sample support request.

Click Save in the webhook dialog.

Make generates a unique webhook URL for Support Request Inbox.

Copy the generated webhook URL using the copy control beside it.
Store the copied address here: your Support Request Inbox webhook URL.

Keep the webhook URL private

Anyone with this address could submit data to your scenario. Keep it out of shared screenshots.

No webhook URL showing?

Reopen the Custom webhook module on the scenario canvas.
Confirm Support Request Inbox is selected in the Webhook field.
Click Save to generate its URL.

I cannot see the generated URL for my Make custom webhook.

Prepare the Postman request

The webhook URL is the destination for a new request. The POST method lets Postman send the sample body to that destination.

Return to Postman in Safari.
Select HTTP from Postman's request creation menu.

You will see a blank HTTP request tab with a method menu and a URL field.

Select POST from the method menu.
Paste your Support Request Inbox webhook URL into the request URL field.

The request now points to the custom webhook waiting in Make.

Select the Body tab below the request URL.
Select raw as the body type.

Postman displays an editor where you can enter the request body.

Select JSON from the format menu.

The request is now configured to send a JSON body to Make.

Capture the sample payload

A custom webhook learns its fields from a sample request. Make uses this captured structure to expose each field for mapping later.

Return to Make in Safari.
Confirm the Support Request Inbox webhook is waiting to capture sample data.

The waiting state confirms that Make is listening for the next request sent to the generated URL.

Return to the Postman webhook request.
Paste this sample into the raw JSON body editor:

{
  "request": "test",
  "conversationID": "333333"
}

What does this sample teach Make?

The request field holds the customer message that the router receives.
The conversationID field identifies the conversation associated with that message.
The sample values give Make enough information to determine the structure of both fields.

Before you click Send, pause to predict the two field names Make will discover.

Click Send in Postman.

Postman receives HTTP status 200 with the body Accepted.

Return to Make in Safari.

You will see Successfully determined below the webhook URL. This confirms that Make captured the sample structure.

Select the numbered output bubble above the webhook module.
Expand the captured bundle.
Confirm the bundle contains request with the value test.
Confirm the bundle contains conversationID with the value 333333.
Click Save in the webhook module.
Click Save in the Scenario Builder toolbar.

That intake path is working. Your scenario can now receive a support request and identify both captured fields.

Make did not determine the fields?

Confirm the Postman method is POST.
Confirm Body uses raw with the JSON format.
Restart sample capture in the Support Request Inbox module.
Click Send in Postman again.

Help me troubleshoot why Make is not capturing my Postman sample.

✔️ My webhook inbox is ready

Your Support Request Router scenario is saved with the Support Request Inbox trigger.

ⓧ I'd like to double check the setup

Use this checklist to compare your scenario with the target setup.

Confirm the open scenario is named Support Request Router.
Confirm the scenario contains the Support Request Inbox custom webhook trigger.
Confirm the Postman webhook request uses POST.
Confirm the request URL matches your Support Request Inbox webhook URL.
Confirm the raw JSON body matches this exact sample:

{
  "request": "test",
  "conversationID": "333333"
}

Why this payload matches

This body contains the exact sample values used to configure the webhook. Make should capture request and conversationID as separate fields.

Confirm Make displayed Successfully determined after the sample arrived.
Confirm the captured data includes request.
Confirm the captured data includes conversationID.

Your support router now has a working inbox for incoming JSON requests. Next, you will give each captured message to an AI agent for triage.

Add an AI Triage Agent

Your Support Request Inbox now gives your Make scenario a working webhook. Each Postman request can reach the automation.

The webhook still cannot interpret the customer's message. This step adds Make AI Agent (New) for first-pass support triage.

In this step, get ready to:

Add the Run an agent module after Support Request Inbox.
Configure the agent for text triage with mapped webhook data.
Test the agent with a billing request.

Add the agent module

Each Make module handles one stage of a scenario. The agent module receives the bundle captured by Support Request Inbox.

In Scenario Builder, click the plus icon to the right of Support Request Inbox.
Enter Make AI Agent (New) in the app search field.

The app picker should show Make AI Agent (New) in the results.

Select Make AI Agent (New).
Select Run an agent.

You should see the Run an agent configuration panel.

Click Add in the Connection field.
Select Make's AI Provider in the connection window.

The new connection should use Make's AI Provider.

Save the new connection.
Select Small in the Model field.

The Connection field should show Make's AI Provider. The Model field should show Small.

Why use the Small model?

Make recommends smaller models for simple categorizing or routing. The Small tier uses fewer credits per equivalent token volume than the Large tier.

Having trouble creating the connection?

Confirm that Make's AI Provider is selected in the connection window.
Confirm that you are configuring the Run an agent module from Make AI Agent (New).

Help me configure the Make AI Provider connection.

Configure the triage inputs

The instruction gives the agent one stable job. Data mapping supplies the live values captured by the webhook.

Select Text in the Response format field.
Set the Instructions field by pasting this text:

You are a support triage assistant. Classify each request by department and urgency, then explain your decision.

What does this instruction do?

The opening role keeps the agent focused on support triage.
Department identifies the destination for the request.
Urgency identifies how quickly the request needs attention.
The final clause asks the agent to explain its decision.

Click the Input field.
Select request from Support Request Inbox.

The Input field should now contain the mapped request value.

Click the Conversation ID field.
Select conversationID from Support Request Inbox.

The Conversation ID field should now contain the mapped conversationID value.

Save the module.
Click the Run an agent module to reopen its settings.

The saved module should show Text in Response format.

The Input field should show request. The Conversation ID field should show conversationID.

Cannot find the webhook fields?

Confirm that you selected the mapping panel for the correct field.
Look for request beneath Support Request Inbox when mapping Input.
Look for conversationID beneath Support Request Inbox when mapping Conversation ID.

Help me find the webhook fields in Make.

Run the first-pass triage

Run once performs a one-time execution of an inactive scenario. This test captures one billing request through the two-module flow.

Click Run once in the Scenario Builder toolbar.

The scenario should wait for one incoming webhook request.

Switch back to the Postman webhook request from earlier.
Replace the request value test with I was charged twice and need the money back today..

Before you click Send, consider whether the agent will return separate fields or one combined answer.

Click Send in Postman.

Postman should receive status 200 with the body Accepted.

Switch back to the Support Request Router scenario in Make.
Click the output bubble above the Run an agent module.

The module inspector should open with the data produced by this execution.

Open Output.
Inspect the Response field.

The exact wording can vary. The Response field should contain one prose answer describing a department and urgency.

The useful values are mixed into that single block of text. This is the intended shortfall for the first-pass agent.

You have your first working AI triage decision. Its response has exposed the data-shape problem that dependable routing must solve.

No AI response in Make?

Confirm that Run once was active before you clicked Send.
Confirm that Postman still uses the webhook URL from Support Request Inbox.
Confirm that the Postman Body remains configured as raw JSON.

Help me find the missing AI response.

Your agent can now interpret a support request. Next, you will give each routing decision its own named field so the workflow can map it reliably.

Structure the Routing Data

Your Make scenario already receives a support request through its webhook. The first AI run also proved that the request can be classified.

The current prose response mixes every useful detail into one block of text. This step configures Make AI Agent (New) to return four named fields that downstream modules can map reliably.

In this step, get ready to:

Replace the loose triage instruction with a fixed routing policy.
Define separate Text fields for the routing decision.
Run a duplicate-charge request and inspect the structured result.

Replace the loose instruction

A clear routing policy limits the labels that the agent can choose. It also defines the situations that deserve urgent attention.

Return to the open Support Request Router scenario in Make.
Select the existing Run an agent module.

You should see the existing Make's AI Provider connection with the Small model. The webhook fields should remain mapped to Input and Conversation ID.

Select all existing text in Instructions.
Replace the selected text with this routing policy by pasting the text below:

You are a support triage agent.
Departments: Billing, Technical, Account, General.
Urgency: Urgent or Standard.
Use Urgent only for blocked access, duplicate charges, security concerns, or deadlines today.
Use only the listed labels. If uncertain, choose General. Never invent customer details.

What does this policy control?

The department list gives the agent four consistent destinations.
The urgency rule reserves Urgent for specific situations that need faster attention.
The final rules keep uncertain requests in General without adding unsupported customer details.

Confirm that the instruction starts with You are a support triage agent..
Confirm that the instruction ends with Never invent customer details..

Instruction not fitting cleanly?

Delete the old sentence before pasting the new policy.
Check that all six lines appear inside the same instruction field.

Ask for help checking the policy if the field still looks wrong: Help me compare my Make AI Agent instruction with the required routing policy.

Create the routing schema

A schema gives every decision a stable shape. Each output value receives its own name and data type.

Think of the schema as a form that the agent completes for every request. The same four boxes appear after every run.

Select Data structure from Response format.

The module should now show controls for adding custom output items.

Create a Text item named department with Add item.
Create a Text item named urgency with Add item.

The output item list should now show department followed by urgency.

Create a Text item named summary with Add item.
Create a Text item named reason with Add item.

The completed schema should list department, urgency, summary, and reason as Text items.

Save the updated agent module.

That is the key upgrade complete: your agent now has named outputs that later modules can map directly.

Missing one of the four fields?

Return to the output item list inside the Run an agent module.
Compare every item name with the required lowercase spelling.
Set every item type to Text.

Use this prompt for help with an incomplete schema: Help me find the missing or incorrectly named field in my Make AI Agent data structure.

Test the structured decision

The schema proves its value when a live request fills each field. You will reuse the duplicate-charge request from your earlier Postman test.

Start a one-time execution in Make by clicking Run once.

The scenario is now waiting for the next request sent to the Support Request Inbox.

Before you send the duplicate-charge request, which department and urgency labels do you expect the agent to choose?

Return to the existing Postman webhook request.
Send the duplicate-charge payload by clicking Send.

Postman should display Accepted in the response pane while Make completes the scenario run.

Return to the Support Request Router scenario in Make.
Select the output bubble above the Run an agent module.
Open Output.

You should see populated department, urgency, summary, and reason fields. The useful routing values now appear separately.

Open Reasoning after checking the structured output.
Confirm that the panel reflects the new routing policy.
Confirm that the panel includes the mapped support request as input.

The reasoning view connects your policy to the structured decision produced by the agent.

Structured fields not populated?

Make sure Run once was waiting before you clicked Send in Postman.
Confirm that the Postman request still uses POST with the Support Request Inbox webhook URL.
Check that the request body still includes request and conversationID.

Ask for targeted help if the module still returns an empty field: Help me trace why my Make AI Agent data structure fields are not populated after a Postman request.

Your agent now produces a routing decision with four dependable fields. Next, you will return those fields to Postman as JSON.

Return a Live Routing Decision

Your AI agent now turns each support message into four named fields. That structured decision is ready to leave the scenario.

A decision visible only inside Make cannot serve the app that submitted the request. In this step, you return an HTTP response from your webhook as JSON to Postman.

In this step, get ready to:

Build a Webhook response from the agent's four outputs.
Publish the response as application/json through an active scenario.
Compare JSON decisions across three support categories.

Add the webhook response

The Webhook response module closes the request-response loop. Its body contains the agent's current output tokens.

Add a module after the existing Run an agent module by clicking the plus icon on its right.
Search for Webhooks in the module picker.

The module picker now lists the available Webhooks actions.

Select Webhook response.

The Webhook response setup panel gives you a Body field for the outgoing reply.

Build a JSON object in the Body field with the keys department, urgency, summary, and reason.
Map every key to the matching structured output from the Run an agent module.

How should the response body be shaped?

The four keys follow the order department, urgency, summary, and reason.
Each key sits inside double quotes.
Each mapped text output sits inside double quotes.
A colon separates each key from its mapped output.
Commas separate the four key-value pairs.
Curly braces wrap the complete object.

This data mapping keeps the response connected to the latest agent decision.

Click Save in the Webhook response module.
Click Run once in the scenario toolbar.

The scenario is now waiting for one support request.

Switch back to your existing Postman webhook request.
Click Send.

The Response pane should now contain a JSON object with department, urgency, summary, and reason keys.

That is the loop closed: Postman now receives the routing decision produced inside Make.

Still receiving the default response?

Confirm the Webhook response module comes after the Run an agent module.
Confirm you saved the Webhook response module before clicking Run once.
Check the body for missing braces, commas, or double quotes if the returned text is malformed.

Help me fix a webhook response that still returns Accepted.

Set the JSON response header

A custom response header identifies the body as JSON. The calling app can then interpret the four fields as structured data.

Return to the Webhook response module.
Open Advanced settings.

Advanced settings exposes the controls for custom response headers.

Add a custom header.

A new header row gives you separate Key and Value fields.

Enter content-type in the Key field.
Enter application/json in the Value field.

What does this header tell the caller?

The content-type header describes the format of the response body. Its application/json value tells Postman that the returned object contains JSON data.

Click Save in the Webhook response module.
Click the scenario's Save control.

The saved scenario now contains the Support Request Inbox, the structured AI triage agent, and the Webhook response module.

Toggle Immediately as data arrives to activate the scenario.

The scenario should now show an active state. New webhook requests can run without Run once.

Scenario still inactive?

Confirm every module has been saved.
Confirm the scenario itself has been saved.
Return to the scenario details if the activation control is unavailable in the builder.

Help me activate my saved Make scenario for immediate webhook requests.

Compare live routing decisions

One successful response proves the connection works. Three different messages show whether the same response shape supports different routing decisions.

Keep your test data synthetic

Use invented support messages for every test. Keep real names, account details, billing information, and the generated webhook URL private.

Before you test these messages, which parts of the JSON response do you expect to remain consistent across all three requests?

Switch back to the existing Postman webhook request.

This request already points to the Support Request Inbox URL. Its raw JSON body already contains request and conversationID fields.

Replace the request value with I was charged twice and need the money back today..
Replace the conversationID value with billing-001.
Click Send.

You should receive the four JSON fields. The duplicate-charge rule should produce Billing as the department with Urgent as the urgency.

Replace the request value with The settings page shows an error when I try to save my preferences..
Replace the conversationID value with technical-001.
Click Send.

You should receive the same four JSON fields. This request should produce Technical as the department with Standard as the urgency.

Replace the request value with I need to update the email address on my account..
Replace the conversationID value with account-001.
Click Send.

Postman's Response pane should display valid JSON containing department, urgency, summary, and reason.

The account request should produce Account as the department with Standard as the urgency.

That is the final handoff working: another app can now consume your router's decision.

Seeing missing fields or invalid JSON?

Confirm the response body contains all four keys.
Confirm every key maps to the matching output from the Run an agent module.
Check the response body for missing double quotes, commas, or curly braces.
Confirm the custom header uses content-type as its key with application/json as its value.

Help me troubleshoot missing fields or malformed JSON in my Postman response.

Secret mission

Split Urgent Requests from the Queue

Your router already identifies urgent support requests. Extend it with separate human-review and standard-support paths so the classification controls what the automation does next.

Clean Up Your Resources

Your automation can stay on the free plans. Each new request still uses Make credits while the scenario is active, so choose whether to keep it running, pause it, or delete it.

Resources you used:

The active Make scenario named Support Request Router.
The custom webhook named Support Request Inbox.

Keep everything running

No action needed. Choose this if you want to keep testing your support router with synthetic requests.

Keep the Support Request Router scenario active for continued tests.
Keep the generated Support Request Inbox webhook URL private.
Send only synthetic requests through Postman.
Monitor your remaining Make credits before sending more tests.

Pause - I'll come back to this later

Shut down automatic scenario runs to preserve Make credits. Your modules, routes, and response mappings remain ready for later.

In the Make tab from earlier, select Scenarios.
Select Support Request Router.
Click the ON/OFF button to make the scenario inactive.

Your scenario is now inactive. You can still use Run once for deliberate tests.

Delete - I don't want to use this again

Removing a working automation can feel final. Make keeps the trashed scenario for 30 days before permanently deleting it.

In the Make tab from earlier, select Scenarios.
Locate Support Request Router.
Open the scenario's three-dot menu.
Select Move to trash.
Select Webhooks.
Click Delete next to Support Request Inbox.
Click Delete to confirm.

The scenario now sits in trash for its 30-day retention period. You should no longer see Support Request Inbox in the webhook list.

Nice Work!

You did it! Your Support Request Router now turns synthetic customer messages into structured JSON decisions through Make. Urgent cases now reach a human-review queue.

You've learned how to:

Send support requests from Postman to a custom webhook that receives the request text plus its conversation ID.
Use Make AI Agent (New) to classify each request into separate department, urgency, summary, and reason fields.
Return a live JSON response that another application can use as a routing decision.
Complete the optional Secret Mission by routing urgent requests to Human Review while sending routine requests to Standard Support.

Ready to quiz yourself?