Chat forms: turn a customer question into a clear enquiry

Use a chat form when your team needs a small, consistent set of details to act on a request. A quote request needs a description and a way to reply. A callback needs a telephone number and a suitable time. A support case needs enough context to identify the problem. A form keeps those details together and connected to the conversation.

A published form can be offered by the AI assistant when its offering instruction fits the conversation. An operator can also send it after taking control of a website conversation. The visitor fills in the details inside the widget, and your team receives a structured response linked to the chat.

With a configured outgoing webhook, those answers can also reach your CRM or a workflow in Make or Zapier. Your receiving system decides what happens next.

Let the assistant or an operator offer the form

In the Offering tab, describe when the assistant should use the form. For a workshop enquiry, the instruction might be:

Offer this form when a visitor asks for a price quote for a workshop for their team.

After publication, the assistant can choose a suitable form from the available catalog. It considers the conversation and your description; configuring an instruction does not make the form appear every time a particular word is mentioned. Test several realistic types of request before using it with visitors.

To send a form manually only, leave the automatic offering field empty. An operator takes control of the website conversation, selects a published form from the composer and chooses an available language. The visitor always fills in the form.

Start with the decision your team needs to make

Before adding fields, finish this sentence: “With these answers, we can…” If the answer is “decide who should call back,” collect enough to make that decision. Information needed later can wait.

This table is a starting point, not a requirement to collect every field. A callback during a live conversation may need just a phone number and topic. A quote for a workshop may need a participant count but no postal address.

1. A quote request that is possible to answer

Consider a business that runs team workshops. “Please send me an offer” leaves the organizer guessing. A useful form asks for a reply address, workshop topic, approximate number of participants, and any important constraints. Make a date preference optional if the visitor is still exploring.

Use labels that explain what belongs in each field:

• What should the workshop cover? Include the topic or the outcome you need.
• Approximate number of participants. An estimate is enough for an initial enquiry.
• Anything we need to plan around? For example, an on-site location or a preferred month.

An operator can introduce it with: “I can send a short form so our team has the details needed to prepare a proposal.” The confirmation can say: “Your enquiry has been submitted. Our team will review the details before confirming a proposal.” Add a response deadline only when your process supports it.

Do not make budget mandatory unless it changes the next decision. An unnecessary question can leave you with a complete form and an incomplete understanding of the actual request.

2. A callback request with realistic expectations

A phone number alone is rarely enough to plan a useful call. Add a short topic and an optional preferred time. If you serve several regions, ask for the time zone or describe the time zone your team uses.

Suitable introductory copy is:

Please leave a number and a short description of what you would like to discuss. You can also suggest a convenient time for a call.

Keep the confirmation explicit:

Your callback request has been submitted. The suggested time is a preference; our team still needs to confirm availability.

A submitted form does not reserve a calendar slot or start a call. For an actual booking, you need a separate booking workflow. Breezaro's Custom Actions can connect to a booking service when configured appropriately; submitting this form does not run that action.

3. A support case with enough context

Ask the visitor to describe what they were trying to do, what happened instead, and what they have already tried. A product reference may help identify the item. Avoid requesting information that the operator can already understand from the conversation.

A useful description prompt is:

What were you trying to do, and what happened? Please describe any error message and the steps you have already tried.

Do not request passwords, payment-card details, or one-time login codes. A reference typed into a form is not verified ownership of an account or order. Any later disclosure of account data still needs the appropriate identity and authorization checks.

If a screenshot or document is needed, direct the visitor to an upload route your business actually provides. Do not promise an attachment field that has not been configured or is not supported.

From the editor to a handled response

1. Choose one use case. Start from a suitable template or a blank form. Give it a public title that makes its purpose clear.
2. Write and arrange the fields in Content. Mark only necessary fields as required. Preview both the regular and narrow widget layouts.
3. Complete the public copy in Settings. Add the submit button text, confirmation message and your privacy-information link. Explain what the team will do next in language you can stand behind.
4. Prepare the available languages. Add the copy for languages configured for the assistant and confirm that the translations have been reviewed.
5. Configure the assistant in Offering. Describe a suitable situation for an automatic offer, or leave the field empty for manual sending.
6. Publish and test. Saving a draft does not change what visitors receive. Copy and offering instructions take effect after publication. Try the language and offering method you intend to use.
7. Review and process the response. Open it from the conversation card or the responses overview, follow up through your established process, and mark it processed once the agreed work is complete.

Responses can be filtered by processing state, marked individually or in bulk, and returned to pending when necessary. Decide internally whether “processed” means a first reply or a finished case. A shared definition prevents one colleague from closing work another still expects to handle.

Prepare copy for your visitors' languages

The form's language variants follow the assistant configuration and share the same fields, layout and validation. You translate public copy such as the title, labels, choices and confirmation. Breezaro does not translate it automatically. Review the affected translations again after changing the default content.

Before publication, the editor shows which languages are ready and where the default language will be used. For automatic offers, the assistant uses an available published variant for the widget content language, or the default variant. System messages and validation copy follow the widget's English or Czech interface.

Send responses to your CRM or automations

An outgoing webhook sends the form reference and entered answers to a receiver you configure. Your CRM or a workflow in Make or Zapier can then create a lead, route a support request or notify your team.

Webhooks are available from Standard, during an active trial or with another explicit access grant. Forms availability alone does not enable Webhooks.

For the same assistant, open Webhooks, configure the receiving HTTPS URL and explicitly select Form submitted (form.submitted). Existing endpoints do not subscribe automatically.

Below the event, choose which forms this endpoint may receive:

• Selected forms: select at least one form. Only submissions from the selected forms are sent to this endpoint. Forms you create later are not added automatically.
• All forms: explicitly choose this option to receive submissions from all current and future forms for this assistant.

Save the endpoint after choosing its forms. Your receiver can use data.form.id to route the responses it receives.

Use Send samples to map the fictional payload. Then submit a published form with fictional details and check the delivery history. Deduplicate by the event id, because retries can deliver the same event again.

Follow the Forms webhook setup and the Webhooks guide for the full configuration.

Keep submitted details in the right place

Breezaro keeps filled-in values out of the assistant's model context. The assistant receives the form's title and status; authorized team members can open the actual answers. Avoid copying those answers back into ordinary chat just to make the AI use them, because that changes where the information travels.

A submission does not itself reserve a slot, run a Custom Action or send a follow-up email. Your team or the receiving system handles those next steps. Authorized users can erase response values in Breezaro, which stops later form deliveries; copies already accepted by your receiver must also follow its retention and erasure rules.

Check the plan and the whole journey

Forms are available on every plan. Your plan sets the number of form slots; an active trial has a separate trial limit. Manual sending requires Take Control, available from Pro and during an active trial. These forms are for the website widget, not native forms in WhatsApp, Messenger, or Instagram. Review chat forms, Take Control, and the current plans together when choosing your setup.

Start with one form and submit a fictional test enquiry. Check the confirmation, find the answer as an authorized teammate, open the related conversation, and mark the item processed. Then test a missing required field and a narrow screen. Once the whole path works, add the next form your team actually needs.