Yaplet has four ways to collect input from your visitors: forms, surveys, bug reports, and feature request boards. They look similar on the surface but serve very different purposes. Pick the wrong one and you'll be wrestling the tool instead of using it.
At a glance
| You want to… | Use… |
|---|---|
| Collect structured data (contact, order, application, onboarding) | Form |
| Measure satisfaction, NPS, or run a multi-step questionnaire | Survey |
| Let users report bugs with screenshots and session replay | Bug reporting |
| Collect feature ideas, let users vote and see your roadmap | Feedback board |
Forms
A form is a blank canvas with structured fields — short text, long text, single choice, multiple choice, numeric scale, and file upload. Use a form whenever you need a specific set of answers that flow into a ticket: a contact request, a bug intake with custom questions, an onboarding questionnaire, a job application. Every submission lands on a kanban board as a ticket that your team can triage, assign, and act on.
A form always belongs to the board it feeds, and you build it on that board's Forms tab: Communications → Tickets → (the board) → Forms. There is no organisation-wide list of forms. Visitors reach a form from your chat widget's home screen, from an agent who sends it during a chat, or from a form step inside a chat workflow.
Surveys
Surveys live inside the Yaplet widget as conversational, step-by-step questions. They're best for measuring sentiment at scale — NPS after a conversation closes, CSAT at the end of an onboarding flow, a quick pulse check triggered by time on page. Surveys are set up at Marketing → Engagement, not alongside your forms, because they're triggered by behaviour rather than user intent.
If your goal is measurement and analytics rather than structured data collection, use a survey. Learn how to create your first NPS survey.
Bug reporting
Bug reporting is Yaplet's heritage feature. One click from your widget and the user's report bundles a screenshot (with optional annotations), a short screen recording, a session replay of the browsing that led up to the report, browser console logs, network logs, and full device metadata — all attached to a ticket on your bug board. No form filling beyond a brief description.
Use bug reporting when your primary goal is quality assurance and you want automatic context instead of relying on users to describe what happened.
Feedback boards and the public roadmap
A feature request board lets visitors submit ideas, vote on existing requests, and watch them progress through columns you define ("Under review", "Planned", "In progress", "Shipped"). The board has a public roadmap page your visitors can browse and bookmark, and the same list can appear as a tab inside your chat widget.
Use a feedback board when you want a persistent, community-visible backlog of user ideas — not a one-off form response.
What you need to buy
Forms, boards and bug tracking all come from one add-on: Feedback boards & bug tracker, $15 a month. It unlocks tickets, board management and the form builder together. There is no separate Forms product — a form's only job is to file a ticket on a board, so the two were never usable apart.
One thing to watch for at the moment of purchase: the add-on is listed only as "Feedback boards & bug tracker" and never mentions forms by name. The form builder is included all the same.
Can I combine them?
Yes. A common setup: a form as your primary support intake, a bug reporting button next to it, and a feedback board shown as a tab in the widget. Each tool feeds a different board so your team sees bug reports, support tickets, and feature requests in separate queues.