Skip to content
InfraCortex

Internal project

InfraCortex Website: From Service Selection to Calendar

We connect service explanations, a brief task description, and call scheduling into one coherent flow. This page describes the studio's internal implementation.

Local implementation · preparing for publication

InfraCortex homepage: the studio's own website.
Our own project interface

Task and user journey

The visitor selects a service track, reviews the specific scope, and proceeds to consultation. In the form, they describe their task and optionally specify systems and budget. Once required fields are validated, a calendar opens with availability from Cal.com.

Implementation details

The selected time slot is re-checked before transitioning to the booking service. A meeting is considered booked only after final confirmation in Cal.com. The local page does not display a fabricated booking success message.

What has been implemented

  • Shared fonts, assets, icons, and responsive components for service pages.
  • A form with required field validation, draft saving in the current tab, and track selection.
  • A calendar that reads live availability and shows an error state if it cannot be retrieved.
  • Keyboard navigation for the form and calendar, reduced motion mode, and visible focus styles.

How it works

One possible scenario

  1. Service selection

    The visitor understands the service offer and the next step.

  2. Client portal

    The client sees their documents, orders, or work progress.

  3. Next action

    You can submit an inquiry, confirm details, or ask a question.

Verification boundaries

The implementation is verified in a local browser. This is not a claim about an already published version, conversion rate, or commercial outcome. The test does not create an actual meeting.

Implementation details

Time slot availability depends on an external calendar. When its response is unavailable, the page suggests retrying or opening Cal.com. Personal brief details are transferred to Cal.com only after explicitly proceeding to confirmation.

What we check after publication approval

Routes on the public domain, behavior on real phones, and the complete path from an inquiry to the team's work. Only after this can baseline metrics be gathered to check where users drop off.

Implementation details

The first step for a similar project is to agree on a single conversion action, page content, and the service where the team will handle the inquiry.

Next step

Need a similar path for your service?

Discuss the task