Why BookFront starts with rules

A calendar link knows when I am free. It does not know whether a call is useful, what the visitor needs, or what I should prepare before we meet.

BookFront adds that missing front door: qualification, intake, an optional payment step, scheduling, and a prep brief.

Prove the workflow before the scoring

Fit scoring is deterministic today. The rules sit behind a small interface that can support a model later, but the rest of the product does not depend on that change.

That order matters. If the questions are poor, better scoring will not rescue the intake. If the payment or scheduling handoff is confusing, a smarter FAQ will not fix the booking experience.

Rules make the current behavior inspectable. I can trace why a visitor received a result, write exact tests for it, and change the product questions without also debugging model output.

The contract is the useful part

The scoring implementation receives structured intake answers and returns a result the interface understands. The page does not care whether that result came from rules or a model, and the scheduling flow does not have to be rewritten when the implementation changes.

What comes next

The live Phase 0 demo covers the complete booking path. The next step is not “add AI.” It is to learn which qualification questions distinguish a useful call, where people abandon the intake, and what information actually helps before the meeting.

Once those decisions are grounded in use, a different scoring implementation can improve the known workflow instead of inventing one.