Boards, items, owners, due dates

AI Chatbot for monday.com: an escalation with an owner beats a transcript nobody opens

Your team does not work from a chat log. It works from a board — groups, items, a status column, a person column, a date column that quietly decides whether you hit your SLA. Asyntai fires four chat events, and each one can become an item on the right board the second it happens, with the visitor's real question in the description instead of "someone needs help".

Get Started Free See the honest setup

See what the chatbot would answer

Enter your website and watch the assistant answer questions using your own content. What it cannot answer is what should reach your board.

Why chat escalations belong on a monday.com board

An operations team measured on response time has one real enemy: work that exists but is not tracked. A conversation sitting in an inbox is invisible. Nobody owns it, no clock is running on it, and it does not appear in the Monday morning review. It becomes a problem only when the customer complains twice.

A board item is the opposite of that. The moment it exists it has a group, a status, a person and a date, and every one of those is a promise your team already knows how to keep. That is the whole argument for pushing chat into monday.com rather than building yet another queue beside it: you are not adding a process, you are dropping the work into the process you already run.

The chatbot handles the ninety percent that is answerable. The board is where the other ten percent goes to get an owner.

There is a second effect that shows up after a few weeks. Once escalations are items, they are countable. You can group them, filter them, and see that a third of them come from one pricing page. A chat log will never tell you that, because nobody reads three hundred transcripts. A board with a category column tells you in one glance.

The four chat events that can open a monday.com item

Register a webhook in Asyntai under Settings → API and tick whichever of these should fire. One webhook can carry a single event or all four, and you can register more than one webhook if different boards want different traffic.

escalation.requested
A visitor asked for a human. This is the one that should almost always become an item, and the one with a clock attached.
conversation.started
A new conversation opened. Carries the session id and the page the visitor was reading when they opened the widget.
message.received
A visitor sent a message and the chatbot answered. Carries both the question and the answer. High volume, so filter it before it reaches a board.
takeover.started
One of your agents took the conversation over. Useful for marking an item as handled by a person rather than the assistant.

Each delivery is a POST with a small, fixed JSON body: an event field naming what happened and a payload field holding the detail.

What Asyntai sends
// Headers: Content-Type: application/json // X-Webhook-Event: escalation.requested // X-Webhook-Signature: <HMAC-SHA256 of the body, using your secret> { "event": "escalation.requested", "payload": { "session_id": "s_47d2be10", "message": "My invoice is wrong and I need someone to fix it today" } }

How to connect the chatbot to monday.com

Start with the part most pages skip. There is no native monday.com app inside Asyntai, and the webhook cannot call the monday.com API on its own. Asyntai sends exactly three headers — Content-Type, X-Webhook-Event and X-Webhook-Signature — and no way to add a fourth. The monday.com API expects an Authorization token and a GraphQL query, so something has to sit between the two and speak both languages.

That something is a connector: a Make scenario, a Zapier Zap, an n8n workflow, Pabbly, or a short endpoint you host yourself. It is one step, it takes about ten minutes, and it is the same step for every board you later add.

1. Connector
A webhook trigger generates a URL
2. Asyntai
Paste the URL, tick events, set a secret
3. Sample
One real chat teaches it the fields
4. monday.com
Create Item on the board you choose
Create the receiving webhook. In Make, start a scenario with Webhooks → Custom webhook. In Zapier, start a Zap with Webhooks by Zapier → Catch Hook. Either way you get a unique URL that listens for a plain JSON POST. Copy it.
Register it in Asyntai. Open Settings → API, add a webhook, paste the URL, tick the events, and set a signing secret. Asyntai signs every body with HMAC-SHA256 and sends the result in X-Webhook-Signature, so the connector can verify a delivery really came from your account. Webhooks are on the paid plans.
Send one real chat. Both tools learn the shape of the data from a real request rather than from a schema. Open your own widget, ask the chatbot something, then request a human. The fields appear and become mappable.
Add the monday.com step. In Zapier the action is Create Item — "Create a new Item in a board" — with Create Subitem, Create Group and Update Item available beside it. In Make, the monday.com app has modules that create an item on a board and update the column values of a specific item. Choose the board, choose the group, and map the fields.
Decide the column values now, not later. Set status to your intake value, put the visitor question into a long-text column, and set the date column so the SLA view picks the item up. An item created without a status is an item your board views will quietly hide.

A sensible column mapping

Column names differ on every board, so treat this as a shape rather than a recipe. The left column is what the payload gives you; the right is where it usually belongs.

From the chat eventColumn on the boardWhy
payload.messageItem name, truncatedThe item is scannable in the group without opening it.
payload.message, in fullLong text columnThe full question survives, in the visitor's own words.
payload.session_idText columnLets an agent find the conversation in Asyntai in one search.
eventStatus or dropdown columnSeparates a request for a human from a routine new conversation.
Time of deliveryDate columnThis is the field your SLA view and your automations actually read.

In a visual builder the mapping is drag and drop. The expression syntax underneath looks roughly like this, where the number is the webhook step:

Mapping into the item
Item name Chat escalation - {{1.payload.session_id}} Question {{1.payload.message}} Event type {{1.event}}

Build it once with escalation.requested only. Adding the other three events later is a checkbox; unpicking a board flooded by message.received is an afternoon.

Two monday.com workflows worth building first

Both are a webhook trigger plus one or two steps. Neither needs code, and neither changes anything about how the chatbot answers.

The intake group that starts an SLA clock

Point escalation.requested at your support board and drop every item into one intake group with a fixed status. Now your existing monday.com automations do the rest: assign by rotation, notify the channel, colour the item when the date column passes. The chatbot has effectively become another intake channel, and it needs no special handling because it produces the same object every other channel produces.

escalation.requestedwebhookCreate ItemSet status + date

A content board fed by the questions the assistant struggles with

Send message.received through a filter first — only messages from your pricing, delivery or returns pages, say — and create an item on a content board instead of a support board. After two weeks that board is an ordered list of the pages that are not explaining themselves. Fixing the top three usually removes more tickets than any change to the chatbot itself.

message.receivedfilter by pageCreate ItemGroup by page

The other direction: asking the chatbot from a monday.com board

Events flowing out are only half the story. A scenario triggered by a board change can also ask the assistant a question and write the answer back. That is the Asyntai REST API, and it is one POST.

Ask the assistant, get an answer back
# POST /api/v1/chat/ curl -X POST https://asyntai.com/api/v1/chat/ \ -H "X-API-Key: YOUR_API_KEY" \ -H "Content-Type: application/json" \ -d '{"message": "What is the return window for outlet items?", "session_id": "item-8842", "website_id": "YOUR_WEBSITE_ID"}'

The reply arrives in the response field, alongside success and the session_id you passed. Use a stable value as the session id — the item id works nicely — and follow-up calls on the same item are understood as one thread. A support agent opening an item can then see a suggested first reply, drawn from your own published content, already sitting in an update. Full reference is in the API documentation.

What the monday.com connection adds to your chatbot

Signed deliveries

Every POST carries an HMAC-SHA256 signature of the body generated from your secret, so the connector can reject anything that did not come from your account.

Answers from your own content

The assistant answers using your own pages, documents and FAQ entries, so what reaches the board is grounded in what you actually published.

One integration, many boards

The same webhook can fan out. Escalations to support, new conversations to a sales board, filtered questions to content, all decided in the connector.

30+ languages, one item shape

Visitors get replies in their own language automatically, and the payload that lands on the board looks identical whichever language was used.

Filters before the board

Route weekend requests differently, ignore chats from staff IPs, escalate only certain pages. None of that logic has to live in the chatbot.

Two-way by design

Events out through the webhook, questions in through the REST API. The same assistant serves your website visitors and the people working the board.

monday.com chatbot questions

Is there a native monday.com integration in Asyntai?

No, and it is better to say so plainly. Asyntai sends a signed JSON webhook and nothing else. It cannot attach the Authorization token the monday.com API requires, so one connector sits in the middle — a Make scenario, a Zapier Zap, an n8n workflow, Pabbly, or a small endpoint of your own. That connector holds the credentials and creates the item.

Which chat events can create an item?

Four, all configured under Settings → API: message.received, conversation.started, escalation.requested and takeover.started. Each webhook listens to whichever combination you tick, so one board can receive only escalations while another receives every new conversation.

Which connector action actually creates the item?

In Zapier the action is Create Item, described as creating a new item in a board, with Create Subitem, Create Group and Update Item beside it. In Make, the monday.com app includes modules that create an item on a board and update the column values of a specific item. You pick the board and group, then map the chat fields onto your columns.

Can a board automation ask the chatbot a question?

Yes, through the REST API. POST to https://asyntai.com/api/v1/chat/ with an X-API-Key header and a body holding message, session_id and website_id. The answer comes back in the response field, ready to write into an update or a text column.

What does this cost?

Three bills, and it is fair to name all three. Asyntai webhooks and the API need a paid plan — the free plan is 100 messages a month with no API or webhook access, see pricing. monday.com is billed per seat on its own plans. The connector has its own free tier and paid tiers based on how many operations you run, which is the number to watch if you ever enable message.received.

Related pages

The same four events and the same API reach every tool that can receive a JSON POST.

Give every escalation an owner

Build the assistant first, then point one webhook at your board. From that day on, the work the chatbot cannot finish arrives where your team already looks.

Get Started Free