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/multi choice, rating 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.
Forms can be shared as a standalone link, sent mid-conversation in the inbox, or embedded as a step inside a chatbot workflow. They're the most flexible of the four tools.
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 surface in the Outreach and marketing section of your dashboard, not in 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, the last ~30 seconds of session replay, 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-facing roadmap page your visitors can browse and bookmark. When you ship a feature, everyone who voted gets an email notification automatically.
Use a feedback board when you want a persistent, community-visible backlog of user ideas — not a one-off form response.
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 tab in the widget sidebar. Each tool feeds a different board so your team sees bug reports, support tickets, and feature requests in separate queues.