Booking App Starter · Industry version
Discovery calls that qualify, paid sessions that collect, and a calendar that protects deep work — scheduling for consultants, in code you own.
For a consultant, the calendar is the revenue model: free discovery calls that must filter as well as convert, paid sessions that should collect before they start, and focus time that meetings will eat if nothing defends it. This starter encodes those rules and hands you the code.
01 · The problem
A consultant's booking types carry different economics, and generic links flatten them. A discovery call is free but must qualify — budget, timeline, fit — before it earns thirty minutes; a strategy session is billable and should be paid at booking; a client on retainer books against hours already sold. One 'pick a time' page with one form treats a tire-kicker and a retained client identically, which is exactly backwards.
Unqualified meetings are the expensive kind of busy. When the booking page asks nothing, the calendar fills with calls that a two-question form would have filtered — and the answers that would have made the call useful arrive during it. Qualification belongs in the booking flow, with rules about what earns a slot.
Firms add a routing problem. Three partners share an inbound stream; bookings should rotate fairly, respect each partner's specialty, and land on the calendar of someone actually available that week. Doing this by forwarding emails is how inbound leads age three days before anyone claims them.
02 · Data model
Everything in the base Booking starter —
servicesprovidersavailability_slotsbookingscustomersreminders— plus the entities this industry actually runs on:
| table | what it holds |
|---|---|
meeting_types | Each way clients get your time — free or paid, duration, qualifying questions, and which providers can take it. |
intake_responses | Answers captured at booking — budget, context, goals — attached to the booking and readable before the call, not during it. |
routing_rules | How inbound bookings pick a provider — round-robin, by specialty, by capacity — encoded, not negotiated in a group chat. |
03 · Screens
Each meeting type asks its own questions, and answers can gate the calendar — a budget below your floor sees a resources page instead of your Tuesday. The filter runs before the slot is granted, which is the only time filtering is free.
Billable meeting types collect at booking, so the session starts even and no-show risk is priced in. Retainer clients skip the charge and draw against their hours — the page knows the difference from the client record.
Inbound bookings rotate across partners under your routing rules — specialty match first, then fair distribution, always respecting per-person meeting caps and protected focus blocks. The calendar defends deep work because you told it to.
04 · In practice
A prospect books a discovery slot and answers four questions on the way in. The partner reads the intake the morning of, opens with the real agenda, and the thirty minutes does the work an hour used to — or the answers filtered the call out entirely.
A client books a two-hour session; payment collects at booking and the preparation checklist goes out automatically. No invoice chase afterward, no awkward opening about billing — the commercial part ended before the call began.
Two dozen discovery calls arrive in a month. Routing sends the fintech inquiries to the partner who wants them, distributes the rest evenly, and skips whoever's at their weekly cap. Nobody audits fairness in a spreadsheet, because the rule is code.
Yes — intake answers can gate the calendar per meeting type. Under-budget or out-of-scope responses can route to a polite alternative instead of a slot. The rules are code you control, from a soft nudge to a hard wall.
That's the core design: each meeting type carries its own price, duration, questions, and eligible providers. Free discovery, paid deep-dive, and retainer draw-down coexist on one page without leaking into each other's rules.
Routing rules evaluate in the order you define — specialty match, then load balancing, respecting per-provider caps and protected time. When a rule doesn't fit how your firm shares work, you edit the rule; it's your codebase.
Two-way sync with external calendar services is a standard integration against your own schema — busy time flows in to block slots, bookings flow out as events. The sync code is yours, so firm-specific quirks are fixable rather than tolerable.
Dual7 App Starters
Discovery calls that qualify, paid sessions that collect, and a calendar that protects deep work — scheduling for consultants, in code you own. Describe your version to start — the output is a project you own.