Your video offers a worksheet, but the form asks for a phone number, company details and a project description. Before sending viewers to it, ask what each answer will actually change. A question that serves no immediate purpose does not become useful just because the form can display it.
These video lead form best practices focus on that decision: what to ask, what to leave optional and what to save for a later conversation. They assume you have already decided that a contact request belongs in the viewing experience. Gate timing and lead-export operations are separate tasks.
Video lead form best practices: decide what belongs
Write the viewer’s request in one sentence, then assess each proposed question against it. “Send me the worksheet” calls for different information from “Call me about this service.” Do not start by copying every column from your team’s contact database into the form.
The GOV.UK Design System’s question-page guidance recommends knowing why each question is asked and requesting only information that is needed. That principle is useful here without adopting an entire government-service form pattern for a video player.
Give every proposed field one of four decisions:
- Needed now: without the answer, the team cannot fulfill the specific request.
- Optional context: the answer has a defined use, but its absence does not prevent fulfillment.
- Ask later: the answer belongs to a different decision or a later conversation.
- Remove: nobody can explain how the answer will be used.
This is an editorial planning exercise, not a claim that a player automatically sorts questions or moves them between stages.
Give email, name and phone different jobs
Email: when the offer is to send a resource by email, an address has a direct purpose. Keep the surrounding request specific about the resource. Do not describe a request for one document as if it were a request for every future message your team might send.
Name: decide whether a name is necessary to carry out the request or merely helpful for addressing a response. If the resource can be provided without it, there needs to be a separate reason to make it a condition of receiving the resource.
Phone: connect the number to a promised call or another explicit task. If the offer does not mention a call and nobody is responsible for making one, a phone question deserves reconsideration. Contact details should not introduce a different offer halfway through the form.
For an additional question, write down the decision its answer would affect. “Which part of the demonstration would you like to discuss?” can help someone prepare a requested conversation. A broad “Tell us everything about your business” asks for much more work without defining the needed answer.
Compare three offers before choosing the questions
The following are hypothetical design exercises, not customer results or ready-made Vidzy form templates. They illustrate how the offer changes the information needed.
A worksheet demonstrated in the video
The immediate task is to provide the worksheet by email. Begin with the address needed for that delivery. A phone number or project budget does not help send the file. If the team wants to discuss a project later, make that a separate invitation rather than a hidden condition of getting the worksheet.
A requested callback about a service
A phone number now has a clear role because the viewer is requesting a call. A name may help the person making that call. Review any extra contact fields against the actual process: if email is also required, explain its purpose rather than treating it as automatically necessary. Choose a form implementation that supports the requirements you have verified.
A discussion following a technical demonstration
An email address and one focused context question may give the team enough information to arrange a useful discussion. Ask about the part the viewer wants to explore, rather than demanding a complete specification. Leave detailed discovery for the conversation if those answers are not needed to arrange it.
Separate gate choice from field choice
Deciding whether viewers must submit an email to continue is different from deciding which additional information belongs in the request. Do not assume that an optional gate makes every field optional, or that a required gate makes every available field necessary.
Vidzy supports timed email lead capture, name, phone and a custom field. Its lead gates can require email to continue or allow viewers to skip an optional request. These capabilities provide options for the lead request; they do not establish every field’s requirement rules, validation behavior or suitability for a particular form design.
Use the preview to notice the distinction between the information being requested and the wording around it. Then check your actual viewer-facing form against the field decisions you wrote down. Do not infer behavior from a preview alone.
Make each question understandable without guessing
The W3C tutorial on labeling controls explains how labels identify form controls. Use that guidance when evaluating the form implementation rather than relying on example text inside an input; a screenshot alone cannot establish programmatic labeling or accessibility compliance.
Review the wording at the point where the viewer has to answer. Would someone know what information belongs in the field, why it is requested and whether they may leave it empty? Where an expected format needs explanation, make that instruction available rather than relying on a failed submission to teach it.
Read the request without the video’s narration. A person who paused playback or missed a sentence should still be able to understand the form. If an answer needs a lengthy explanation, reconsider whether that question belongs in this short interaction.
Use a field-review worksheet before configuration
Complete one row for each proposed question in your own planning document. These worksheet columns are not claimed Vidzy fields or software features.
| Worksheet item | What to write |
|---|---|
| Requested information | The exact question the viewer would see. |
| Immediate use | The specific task or decision that needs the answer. |
| Missing-answer consequence | What genuinely cannot happen if the answer is absent. |
| Decision | Needed now, optional context, ask later or remove. |
| Viewer explanation | A short, honest reason for asking, where clarification is needed. |
Have the person responsible for responding review the worksheet. If they cannot name a use for an answer, revisit the question before adding it. If an answer is needed, confirm that the form implementation can collect it in the intended way without assuming unverified behavior.
Finish by checking the actual form on the page, including its labels, optional-field behavior and what happens after submission. The useful outcome is a request the viewer can understand and your team can act on, not the largest possible contact record.













