Research methodology
How we test online form builders
The Blog uses repeatable workflows, pre-published criteria, current primary sources and visible limitations so a reader can inspect how a conclusion was reached.
Four repeated scenarios
- Lead qualification.Eight questions, two branches, a lead score, three outcomes, contact capture, CRM mapping and a three-email sequence.
- Product recommendation.Five preference questions, answer-based outcomes, three recommendations and personalized follow-up.
- ROI calculator.Four numeric inputs, a formula, hidden attribution fields, a personalized result and result delivery.
- Simple-form baseline.A contact or RSVP form used to test speed, accessibility, free limits, spam controls and export.
Base scoring model
The weights are fixed before a comparison begins. A category-specific rubric is allowed only when it is registered before products are scored.
| Dimension | Weight |
|---|---|
| Core task completion | 15% |
| Logic, scoring and outcomes | 15% |
| Post-submit email and automation | 15% |
| CRM mapping and data portability | 15% |
| Analytics and attribution | 10% |
| Respondent UX and accessibility | 10% |
| Builder ease and implementation time | 5% |
| Security and data-quality controls | 5% |
| Total cost of ownership | 10% |
Evidence record
Each test records the plan, date, country, account type, time to first valid publish, completed and failed requirements, screenshots, key clicks, logic behavior, follow-up capabilities, data mapping, analytics, spam controls, accessibility checks, cost, official sources and retest date.
A capability is not marked as included because a vendor uses a broad category label. The exact plan and tested workflow must support it. When documentation is ambiguous, the narrower interpretation is used.
Conflicts, vendor input and limitations
Vendors cannot buy Blog inclusion, placement or a higher score. A conflict check is completed before vendor comparisons, and a product with an editorial conflict is excluded from Blog coverage. Vendors may correct a factual error or clarify current documentation, but they do not choose the test, competitors or verdict.
A passing scenario shows that a workflow worked in the recorded conditions. It does not prove universal reliability, suitability for regulated data or identical behavior on every plan. Articles state those limits explicitly.