Preflight vs Technical Intake
Preflight proves package fit before checkout; technical intake collects the operational detail needed to fulfil an already selected engagement.
Definition
Preflight is the routing step before checkout or qualification. Technical intake is the later fulfilment step that gathers the information required to implement the accepted scope.
Why it matters to the business
Keeping them separate avoids asking a buyer for a full implementation specification before fit is known and prevents checkout from hiding unresolved scope.
How it works
Preflight asks only what is required to route the buyer. After payment or qualification, technical intake collects systems, mappings, rules, acceptance inputs and access requirements.
Where it appears in real systems
Lead Response and Reporting have standard fit gates; Integration uses Discovery; AI requires qualification; CRM Audit can move to the bounded audit purchase path.
Common failure modes
- The form becomes a full discovery project before purchase.
- Checkout occurs despite unresolved standard-package gates.
- Sensitive credentials are requested during ordinary intake.
Implementation considerations
- Keep checkout short.
- Capture success criteria before implementation.
- Move scope mismatches to review, discovery or re-scope.
When it is appropriate
Use preflight whenever a standard package can fail its published boundary.
When it is not appropriate
Do not use a generic pass/fail gate where the canonical purchase mode is Discovery or qualification.
Relationship to BYFORCE
The BYFORCE state model begins at preflight_started and separates payment, technical intake and access provisioning.
Source basis
- docs/website/BYFORCE_SELF_SERVICE_INTAKE_SPEC_2026-09-23.json