Works with Asana

AI Chatbot for Asana: escalations that enter the intake process you already run

You already have an intake project. It has a triage section, custom fields, a rotation of assignees and rules that move work along. Asyntai answers your website visitors using your own content, and when a question needs a person, it enters that project as a properly formed task — not as a message in a separate tool that somebody has to copy across by hand.

Get Started Free See the honest setup

See what the chatbot would answer

Enter your website and watch the AI answer questions using your own content — the answers that decide what ever reaches your intake project.

Why the chatbot should feed an existing Asana project

Teams that run Asana properly have already done the hard part. Requests come in through one door. They land in a triage section. Somebody owns each one. Custom fields say what type of request it is and how urgent, and rules push work through the sections without anyone chasing it. That process took months to agree on.

So the wrong answer is a new project called Chat. A second intake path defeats the point of having one, and within a quarter it is a graveyard nobody reports on. The right answer is much duller: chat escalations become ordinary tasks in the project that already exists, indistinguishable from a request that arrived by form or by email.

The goal is not to give chat a home in Asana. It is to make chat stop being a separate thing at all.

Done that way, the reporting works immediately. Your intake dashboard counts chat escalations alongside every other request. Your workload view accounts for them. Your response-time field measures them on the same clock. Nobody has to remember that a second queue exists, because it does not.

The four chatbot events, and which belongs in intake

Asyntai fires four webhook events. You choose which ones a given webhook sends.

escalation.requested
A visitor asked for a person. Carries the session id and the message that triggered it. This is the one your intake project wants.
takeover.started
An agent took over from the chatbot. Carries the session id and the agent name. Useful for closing the loop on a task automatically.
conversation.started
A visitor opened a new conversation. Carries the session id, the page they were on and the device type.
message.received
A visitor sent a message and the chatbot answered. Carries the question, the answer, the session id and the page URL.

Send escalation.requested to intake and stop there. The temptation with a structured setup is to capture everything — but a project that receives an event on every single message stops being an intake project and becomes a log, and your cycle-time reporting is the first casualty. Route the other three to a warehouse, a dashboard tool or a weekly digest instead.

How to connect the chatbot to Asana, honestly

One clarification before the steps, because it changes how you plan the work: there is no one-click install here, and Asyntai does not call the Asana API directly.

An Asyntai webhook POSTs JSON to a URL and signs the body. The only headers it sends are Content-Type, X-Webhook-Event and X-Webhook-Signature. There is no field for a custom authentication header — and every Asana API request needs an Authorization token. So a connector holds that token: Make, Zapier, Pabbly, n8n, or an endpoint your own team hosts. For a security review that is usually the easier answer anyway, because the Asana credential lives in a tool you already govern.

1. Connector
A catch-hook or Custom webhook generates a URL
2. Asyntai
Paste the URL, tick the event, set a secret
3. Sample
One real chat teaches the connector the fields
4. Asana
Create Task into the intake project

The four steps in full

Decide the destination first. Pick the existing intake project, the section new requests land in, and the custom fields the task must carry. If your process says every request needs a Request type and a Source, decide now that chat escalations get Support and Website chat.
Get a listening URL from your connector. In Zapier that is the Webhooks by Zapier trigger with Catch Hook. In Make it is Webhooks → Custom webhook. Both generate a unique address and start listening. Copy it.
Register it in Asyntai. Open Settings → API, add a webhook, paste the URL, tick escalation.requested, and set a signing secret used to sign each delivery. Then open your own widget and ask the chatbot for a human, so the connector reads one real payload and learns the field names.
Add the Asana step. Choose Asana as the action app and pick the task creation action — in Zapier it is named Create Task, and it takes a workspace and a task name as required inputs, with optional description, assignee, followers and custom fields. If your intake section is not the default, follow it with Add Task to Section of Project.
What Asyntai POSTs to the connector
// 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_8f31c0a4", "message": "We need the invoice reissued to a different legal entity" } }

Once the connector has read one delivery, those fields are mappable. In Make's expression syntax, where 1 is the webhook module number:

Mapping the payload into the task
Task name: {{1.payload.message}} Notes: Chat session {{1.payload.session_id}} Event: {{1.event}} Assignee: [email protected] Source field: Website chat

What each Asana field should hold

Task name
The visitor's own sentence, from payload.message. Never a generic title — triage happens by reading names in a list view.
Description
The session id plus the event name, so an agent can open the transcript in one search.
Project
Your existing intake project. Not a new one.
Section
Whatever your process calls the untriaged column. Usually Triage, New or Inbox.
Assignee
Leave empty if a rule assigns by rotation. Set it directly if there is one owner.
Custom fields
Source set to Website chat, and Request type set to whatever your taxonomy already uses.

The Asana connection lives in the connector, never in Asyntai. Rotating the token, or repointing intake at a different project after a reorganisation, is a change in one place and never touches your chatbot.

Two Asana workflows worth building first

The first one is the whole feature. The second closes the loop, and is what makes the reporting trustworthy.

An escalation enters triage with its fields already filled

A visitor asks for a person at eleven at night. Within a second there is a task in the Triage section of your intake project, named with the customer's actual sentence, tagged Website chat in the Source field, and holding the session id. Your existing rule then does what it does for every other request: assigns to the person on rota, sets the due date from the service target, and posts to the project's channel. No one changed their process for this.

escalation.requested→Catch Hook→Create Task→Add Task to Section→Asana rule assigns

The task closes itself when an agent picks the conversation up

Tick takeover.started on a second webhook. When one of your people takes over the conversation, the connector searches the intake project for the task carrying that session id and moves it to In progress, with the agent set as assignee. This is the step most teams skip, and it is why their intake numbers drift — work gets done in the chat tool while the task sits open for a week and ruins the cycle-time average.

takeover.started→Catch Hook→Find Task→Update Task

The other direction: Asana can ask the chatbot too

Events flowing out are half of it. Any step that can make an HTTP request — a connector action, a script, a scheduled job — can put a question in and get an answer back, grounded in your own published content.

Enriching a task before anyone opens it
POST https://asyntai.com/api/v1/chat/ X-API-Key: YOUR_API_KEY Content-Type: application/json { "message": "We need the invoice reissued to a different legal entity", "session_id": "s_8f31c0a4", "website_id": "YOUR_WEBSITE_ID" } // Response: { "success": true, "response": "...", "session_id": "..." }

Take the response value and post it as the first comment on the task. The assignee opens a triage item and finds a draft already there, citing what your documentation actually says. Reuse the same session_id and follow-up calls are understood as one thread. Full reference in the API documentation.

What the Asana connection adds to your chatbot

One intake path, not two

Chat escalations arrive in the same project, sections and custom fields as form and email requests, so your reporting stays whole.

Signed deliveries

Each POST carries an HMAC-SHA256 signature of the body, generated from your secret, so a delivery can be verified against your account.

Answers from your own content

The chatbot answers using your own pages, documents and FAQ entries, so only the genuine exceptions reach a person at all.

30+ languages, one task format

Visitors get replies in their own language automatically. The task that reaches triage is structured identically either way.

Your rules still run

It is an ordinary task, so every Asana rule you already wrote for assignment, sections, due dates and approvals applies unchanged.

Credentials stay governed

The Asana token lives in your connector, not in the chat tool, which is usually the shorter conversation with a security reviewer.

What this actually costs

Three products. Only the middle one is likely to be a new line item.

  • Asyntai. Webhooks and the REST API need a paid plan — Starter, Standard or Pro. The free plan gives you 100 messages a month to try the chatbot itself, with no API or webhook access. See pricing.
  • Asana. Its own subscription, which your team already has if you run an intake project with rules and custom fields.
  • The connector. Make, Zapier, Pabbly and n8n bill separately. Two automations firing on escalation.requested and takeover.started are low volume by design and usually fit a free tier. Adding message.received does not, which is the practical reason on top of the reporting one to leave it off.

Asana chatbot questions

How does the chatbot create a task?

Through a connector. Asyntai POSTs signed JSON to any URL you nominate, but it cannot send a custom Authorization header, and every Asana API call needs one. Make, Zapier, Pabbly, n8n or your own endpoint receives the webhook, holds the Asana connection, and calls the task action.

Can the task be assigned and placed in a section?

Yes. Asana structures work as workspace, project, section and task, and a task carries a single assignee. Create Task accepts a workspace, name, description, assignee, followers and custom fields, and Add Task to Section of Project places it. Many teams let their existing rules handle both instead.

Which events should feed the intake project?

escalation.requested only, in most setups, with takeover.started as a second webhook for closing the loop. message.received and conversation.started fire far too often to belong in a project you report on.

Can a rule ask the chatbot for a suggested reply?

Yes. POST to https://asyntai.com/api/v1/chat/ with an X-API-Key header and a body of message, session_id and website_id. The answer arrives in the response field, ready to post as the first task comment.

What does it cost?

Asyntai webhooks and the API are on the paid plans (Starter, Standard, Pro); the free plan's 100 monthly messages do not include them. Asana bills separately, and so does the connector, though a single low-volume automation usually fits a free tier.

Other ways to wire the chatbot in

The same four events and the same API work through any tool that can receive a JSON POST.

Make Zapier n8n Twilio API docs All platforms

Put chat inside the process you already trust

Build the chatbot, point one webhook at your connector, and every request for a person enters triage as a properly formed task with its fields filled in.

Get Started Free