Forms
Forms in LadVen OS collect requests from a website, landing page, documentation page, or external page and turn them into managed CRM work. They are useful for demo requests, customer inquiries, consultation requests, support requests, and other inbound flows.
A form should collect only the data needed for the next step: who contacted you, how to reach them, what they need, and where the request should go.
When to Use Forms
Use forms when you need to collect website requests, route them into the right CRM pipeline, standardize inbound fields, review submissions, separate spam from real work, and know which published version is live.
If a request arrives by email or chat, do not copy it manually without a reason. Link the message or conversation to CRM when that keeps better context.
Choose the Scenario and Owner
Before building a form, decide who owns the scenario: marketing, sales, support, or operations. The owner approves fields, consent text, CRM routing, the first responder, and the rule for closing low-quality submissions.
For every form, define the purpose, placement page, default language, extra languages, required fields, CRM pipeline, first stage, daily reviewer, and the condition for unpublishing or archiving it.
Demo Request Scenario
A demo request should help a person get to product testing quickly. In most cases, name, work contact, company, role, preferred language, and a short description are enough. Do not ask for internal budgets, passwords, tokens, or unnecessary personal data at the first step.
After a test submission, check that it reaches the right owner, the text is clear, the language is consistent, and the source helps the team understand where the person came from.
Customer Inquiry or Support
For consultation, support, or customer inquiries, add fields that help qualification: topic, product area, preferred contact time, attachment only when truly needed, and comment. If the request should go to support or account management instead of sales, use a separate route and owner.
Do not mix different processes in one form. Demo, partner request, and support should usually be separate forms so the team does not sort them manually.
Create the Form
In the builder, set the name, code, primary language, title, description, submit button, and fields. The internal name should make sense to the team; the title and description should make sense to the external person.
Fields should be short and clear: name, contact, company, question, preferred contact time, and comment. If the form has several languages, check the form text and field labels in every language before publishing.
Required Fields and Data Quality
Do not add unnecessary required fields. The longer the form, the less likely the customer is to submit it. Require only the data the team needs to answer or qualify the request.
A good form avoids duplicate questions, uses clear field names, avoids internal abbreviations, never asks the customer to choose an internal CRM stage, and collects consent and contact details in plain language.
Publish and Place the Form
Saving a form does not always change the live website. Before publishing, check the preview, required fields, languages, appearance, anti-spam settings, allowed domains, and CRM routing.
After publishing, place the form only on pages that should accept real submissions. If a form is unpublished or archived, confirm that the website no longer has an active entry point.
Do not show live keys, real contacts, or private links in training materials or demonstrations. To present the form to colleagues, create a separate test form with safe data.
CRM Routing
Choose the pipeline, starting stage, and routing rules for new submissions. If no route is selected, the form may follow shared platform rules.
Good routing makes it clear who sees the request first, where it appears, which fields qualify it, who handles CRM errors, and when the request is accepted.
Submissions and Statuses
Review submissions regularly. A submission should become accepted, spam, or retried after CRM errors are fixed. If it looks suspicious, do not move it into work until the contact and content are checked.
For CRM errors, check required fields, routing, permissions, and customer data before retrying. If the error repeats, send the process owner the exact submission, form, and expected behavior.
Localization and Consent
When a form is available in several languages, check the title, button, field labels, error text, consent text, and responsible-person notification. The sender should see one language throughout the submission path.
Consent text should explain why the data is collected and who processes it. Do not reuse legal copy from another country or process without owner review.
Safety
Do not collect passwords, tokens, passport data, payment details, or other unnecessary sensitive information through public forms. For client-facing forms, agree the consent wording and purpose of data collection in advance. Review allowed domains and active published forms as regularly as public file links.
Manager Checklist
- The form has an owner and a clear scenario.
- Fields match the next business step.
- Required fields are minimal.
- Languages, consent text, and button text are checked.
- A test submission reached the correct CRM pipeline.
- The responsible person knows how to accept, mark spam, and retry delivery.
- The website does not contain an old or archived version.
Common Mistakes
- One form is used for every inbound request.
- The form asks for details the team can clarify later.
- The placement page is not checked after a form change.
- Submissions are copied manually and lose their source.
- Spam goes into the working CRM pipeline.
- For demonstrations, use synthetic contacts and a separate test form with a non-production or masked embed example; never use live contacts or working embed code.
Business Scenarios
- Omnichannel inbox
- Sales pipeline with tasks and documents
- Unified client history: CRM, tasks, documents, chat
- All scenarios
Related Sections