Turn a contact form into an instant first response
Instead of a submission sitting until someone checks the inbox, the assigned employee reads it the moment it arrives and can reply, ask a clarifying question, or route it forward.
Embed a form on your website and route every submission straight to an AI employee, no inbox in between. The employee reads the fields, replies, files a lead, or kicks off a task the moment someone hits submit. This channel is on the roadmap and is not available yet.
Most website forms end the same way: a submission lands in an inbox, a spreadsheet, or a CRM queue, and a person has to notice it, read it, and decide what to do. The Form Channel is built to close that gap. You embed a form on any page, on your site or a landing page, and every submission is routed directly to one of your AI employees instead of sitting in a queue.
The employee that receives the submission treats it like any other message: it reads the fields, follows the instructions and tools you have already given it, and responds or acts within its normal permissions. A support employee can answer a question in the fields directly. A sales employee can qualify the lead and log it. An operations employee can turn a request into a task. The routing rule is set once at the form level, so every future submission goes to the same employee without you touching it again.
What sets this apart from a generic form-to-webhook or form-to-Zapier setup is that the destination is a full AI employee, not a static automation step. A webhook can move data; it cannot read the free-text field the visitor wrote, judge intent, decide whether to escalate, or hold a follow-up conversation with the same context. Because the submission lands inside the employee's normal conversation and tool access, it can act on judgment the way a person reviewing the form would, and the interaction stays visible in the same chat history as every other channel.
The guardrails you already rely on come with it. An employee acting on a submission can only use the tools and duties you gave it, and anything sensitive still goes through the same approval step it would on any other channel, so nothing is sent, spent, or committed on your behalf because a stranger filled in a form. Structured fields and free text arrive together, which is the part a rules-based automation cannot handle: the dropdown tells the employee what category the request is, and the paragraph underneath tells it what the person actually needs.
This channel is on the roadmap and is not available yet, so nothing here describes something you can switch on today. There is no release date to quote. Until it arrives, the closest thing already working is the Webhook channel, which accepts an HTTP POST from a form you already have, and the employee mailbox, which can receive the notification email your current form sends.
The channel is meant for any structured intake you currently collect through a web form: contact requests, support tickets, quote requests, waitlist signups, application forms, or feedback. Anywhere you would otherwise wire a form to an inbox or a spreadsheet, you will instead be able to wire it to an employee that can read and act on it immediately.
Because each form is assigned to a specific employee, different forms on the same site can route to different specialists. A pricing-question form can go to a sales employee while a bug-report form goes to a support employee, without you building separate infrastructure for each.
A submission is not a one-off event that disappears once it is handled. It becomes part of the same conversation record every other channel uses, so a follow-up email or a later chat message from the same person can reference what was submitted through the form.
This also means the usual guardrails apply: the employee acts within the tools and duties it has been given, and any sensitive action it wants to take on the back of a submission still goes through the same approval flow as it would for a message sent from any other channel.
Your employees can already be reached through web chat, voice, Slack, Telegram, an email mailbox of their own, a webhook, a schedule, and the API. Each of those is a different door into the same worker. The Form Channel adds the one door most small businesses actually have on their website, and it will behave like the others rather than like a bolt-on.
If you already collect submissions today, the practical difference is where the reading happens. A form that posts to a spreadsheet needs a person to open the sheet. A form that posts to a webhook can already reach an employee, but you have to build and host the form yourself. The Form Channel is meant to remove that last piece of assembly so the form and the worker ship together.
A form submission becomes a message an employee can act on
You will build the form, choose its fields, and assign it to one employee. When a visitor submits it, the platform packages the field values into a message and delivers it to that employee's conversation, the same delivery path already used for chat, email, and the other channels.
The employee then runs its normal turn: it reads the submission, applies whatever skills, duties, and tools it has been given, and produces a response or an action. Because the message arrives through the same pipeline as any other channel, it shows up in the employee's regular activity and conversation history, so you can see exactly what came in and what the employee did with it.
Nothing about your employee has to be rebuilt for this. Every channel in Sistava hands the same kind of normalised message to the same engine, which is why an employee that already handles chat, email, and Slack will handle form submissions with the skills, duties, tools, and memory it already has. Adding the channel is wiring a new door into a room that is already furnished, not furnishing a second room.
Instead of a submission sitting until someone checks the inbox, the assigned employee reads it the moment it arrives and can reply, ask a clarifying question, or route it forward.
A sales employee reads the fields on a demo-request or quote form, applies your qualification criteria, and logs or escalates the ones that matter, without a rep triaging every submission by hand.
A bug-report or support form is handed to a support employee, which can open a task, ask for reproduction steps, or resolve the simple cases directly, keeping the request out of a raw ticket queue.
Application forms, waitlist signups, and intake questionnaires usually end up in a sheet nobody reads for a week. Routed to an employee instead, each submission gets acknowledged, sorted against your criteria, and the ones worth your attention get surfaced while the rest are logged.
| Before | After |
|---|---|
| A submission lands in an inbox or a spreadsheet and waits for someone to notice it. | Arriving: it goes straight to the assigned AI employee, which reads it and acts the moment it lands. |
| Wiring a form to an automation tool moves the data but cannot read the free-text field. | Arriving: a full AI employee reads the whole submission, weighs what it means, and decides the next step. |
| Every form on your site funnels into one shared inbox no matter what it is about. | Arriving: each form points at its own employee, so a pricing question and a bug report take different paths. |
| Form submissions sit in a separate log from the rest of your customer conversations. | Arriving: they join the same conversation history as chat, email, Slack, and every other channel. |
No. It is on the roadmap and has not shipped yet. This page describes what it will do once it is released.
The goal is an embeddable form you can drop onto any page without building a custom integration, similar to embedding a widget. Exact setup details will be published when the channel ships.
Yes. Each form is assigned to one employee, so you can point a sales form at one employee and a support form at another.
Yes. A submission is delivered into the same employee conversation history used by the other channels, so you see it alongside everything else that employee has handled.
There is no release date to give you. The Form Channel is on the roadmap and no part of it is built yet, so any date would be a guess. This page will describe how to set it up, rather than what it is planned to do, once it actually ships.
Two routes already work. The Webhook channel accepts an HTTP POST, so a form you already host can deliver into an employee's conversation, and every employee has its own email address, so the notification email your current form sends can be pointed at it instead of your inbox.
The intent is for it to be metered exactly like any other employee work: the submission itself is just a message, and what costs anything is the thinking and the actions the employee does in response. The final details will be confirmed when the channel ships.
Whether a reply reaches the visitor depends on the contact details the form collects, and that behaviour has not been finalised. What is certain is that the employee's response and any action it takes land in its conversation inside Sistava, so you can see what was decided either way.
Form Channel is part of Ways you talk to them.
Chat in the app with live reasoning, speak to your AI voice agent over a call, message on Slack or WhatsApp, send an email, or embed a widget on your website. Every channel connects to the same AI agent with the same memory and capabilities. Switch channels mid-conversation and your employee picks up right where you left off.