Skip to content

Discovery: Investigate integration between "Book Your Free Discovery Call" form and potential scheduler (Calendly) #299

@mariana-caldas

Description

@mariana-caldas

What do we need to build or fix?

The Services page design currently includes a two-step lead capture flow:

  1. Initial form in the hero section
  2. A modal with additional project inquiry questions

The intent of this flow is to collect useful background information about potential clients before a discovery call. However, the project currently does not include building a custom scheduling system. Instead, we plan to rely on a third-party scheduling tool (likely Calendly).

This creates a technical question regarding how user information collected in the first step should be handled when the user proceeds to schedule a call.

If this information cannot be passed to the third-party scheduler, users may need to re-enter their details again, which could introduce unnecessary friction and negatively impact conversion.

The goal of this issue is to investigate the technical feasibility and recommended approach for integrating the form with a third-party scheduler.

Design references and screenshots of the current form flow will be attached.


Technical details

The current design includes two parts:

Step 1 — Hero section form

Fields currently shown:

  • Full Name
  • Business or Organization (optional)
  • Email
  • Contact Number
  • Appointment Date

CTA:

Book Now


Step 2 — Modal (Project Inquiry)

Additional fields include:

  • What does your business or organization do?
  • What industry are you in?
  • What problems are you expecting to be solved?
  • Project Budget
  • Which services are you interested in?

CTA:

Confirm and Book Call


Implementation questions to investigate

  1. Can user information collected in the first form be passed to Calendly as prefilled fields?

Example:

https://calendly.com/.../?name=&email=
  1. Are we able to pass custom fields (e.g. company, problem description, service interest)?

  2. If custom field mapping is not supported, should we:

  • remove the pre-form
  • simplify the form
  • or move all qualification questions into Calendly?
  1. Should the Appointment Date field remain in the form, given that Calendly will handle scheduling?

  2. If we maintain the pre-form, do we need a temporary storage layer (API / state / query params) before redirecting to Calendly?


Approach suggestions

Possible implementation paths to evaluate:

Option 1 — Simplified approach (recommended for v1)

Hero form collects minimal information:

  • Name
  • Email
  • Company (optional)

User then opens a Calendly widget, where additional questions can be asked using Calendly's custom question fields.

Pros

  • Simpler implementation
  • Lower user friction
  • Faster development
  • Calendly handles scheduling logic

Option 2 — Prefill Calendly fields

Use the hero form to collect information and pass values through URL parameters when opening Calendly.

Example:

https://calendly.com/demo?name=John%20Doe&email=john@email.com

Pros

  • Reduces repeated input

Cons

  • Limited field mapping
  • Requires additional logic

Option 3 — Full pre-qualification form

Keep the current two-step flow and collect all information before scheduling.

This would likely require:

  • temporary storage
  • passing structured data
  • possible backend integration

This option introduces higher engineering complexity and may not be necessary for the first implementation.


Deadline

Please keep in mind that once you assign this task to yourself, you'll need to complete it in 10 days.


Acceptance criteria

  • Investigate how Calendly integration works for embedded scheduling.
  • Confirm which fields can be prefilled via query parameters.
  • Determine whether custom question responses can be pre-populated.
  • Identify whether the Appointment Date field should remain in the UI.
  • Provide a recommended implementation approach for v1.
  • Document the recommended flow so the team can adjust the UI if needed.

Attachments

Mock-up link

Metadata

Metadata

Assignees

Labels

Type

No type

Projects

Status

Issues

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions