Booking HandbookAsk for the right booking details.
First checks
- Name the purpose and owner
For every proposed field, state the decision or service action it supports, the responsible business owner, the affected services, the people allowed to see it, and the event that ends its usefulness.
- Choose the minimum field
Reuse a dependable core field where appropriate; otherwise choose the least sensitive type, options, precision, format, and required rule that can support the named purpose.
- Separate identity from presentation
Give the field a stable internal key and type. Treat label, help text, option order, translation, position, and styling as presentation that can change without silently changing stored meaning.
Will one answer keep the same meaning everywhere it is used?
Describe the purpose, collection boundary, field identity, required rule, saved destinations, language behavior, edit/version behavior, export mapping, and disposal rule. The result identifies the next design or test priority without collecting a real answer.
Lifecycle destinations remain untested
The field definition is coherent, but one or more lifecycle destinations remain untested. Run the synthetic matrix before relying on it.
Name the decision or action the field supports, responsible owner, permitted viewers, applicable services, and least data needed.
Use a stable internal field and option identity that survives label, translation, order, and styling changes.
Define when the field appears, whether it is required, valid formats, plain-language errors, and what happens when its condition becomes false.
Map the answer and booking context to the intended snapshot, customer profile, staff view, confirmation, messages, calendars, automations, API, and reports.
Keep stable meaning across translated labels, instructions, options, errors, confirmations, and fallbacks; record the locale and wording shown when needed.
Define who may edit, whether the booking or profile changes, what history remains, and how old answers keep their original meaning.
Preserve stable mapping in allowed exports and define the approved archival, retention, or deletion boundary for every copy.
Understand the field-lifecycle rule
Collect for a named purpose
Know why the field exists, who uses it, when it applies, and why a smaller data set is insufficient.
Give it stable identity
Keep a machine-stable field key separate from the customer-facing label, translation, position, and current wording.
Preserve answer meaning
Store the value with its field version, booking context, option identity, locale, and applicable record relationships.
Control every destination
Decide what appears in confirmations, customer and staff records, edits, messages, calendars, exports, and disposal workflows.
Labels change, options move, and downstream records lose the meaning.
A custom field can appear correctly during booking but fail to save, disappear from the client record, become impossible to edit, export under a translated label, print the word undefined when left blank, or silently keep an old answer after the question changes. The lifecycle is the feature.
The lifecycle rule: Trustworthy field lifecycle = named purpose + minimum collection + stable identity + valid answer + explicit destinations + versioned meaning + controlled change + defined disposal
A synthetic group lesson asks for attendee count. The label later changes from “Guests” to “Total attendees,” and a translated form uses another label. A reliable record keeps one stable field key, a numeric value, the label and locale shown at booking, the applicable service, the answer version, and the intended confirmation, staff, export, and deletion behavior.
Follow the complete field-design sequence
A form control is only one surface. The field must keep its purpose, identity, answer meaning, destinations, edit history, and disposal boundary through the complete booking lifecycle.
- Name the purpose and owner
For every proposed field, state the decision or service action it supports, the responsible business owner, the affected services, the people allowed to see it, and the event that ends its usefulness.
- Choose the minimum field
Reuse a dependable core field where appropriate; otherwise choose the least sensitive type, options, precision, format, and required rule that can support the named purpose.
- Separate identity from presentation
Give the field a stable internal key and type. Treat label, help text, option order, translation, position, and styling as presentation that can change without silently changing stored meaning.
- Define applicability and validation
Specify which service, location, provider, customer, party size, language, or prior answer makes the field appear; explain required and optional states; and validate in plain language without erasing other answers.
- Map every answer destination
Decide whether the value belongs to the booking snapshot, reusable customer profile, staff view, customer confirmation, reminder, calendar description, automation, report, API, and export. Blank optional answers must stay blank, not become undefined or fabricated text.
- Control edits, versions, and disposal
Define who may edit an answer, whether the original is retained, how label or option changes affect old bookings, how translations fall back, how exports remain mappable, and when the answer is archived or removed under an approved policy.
Compare five field ownership models
Core identity, one-booking questions, conditional inputs, reusable preferences, and higher-risk acknowledgments need different storage and edit behavior.
Core identity or contact field
Example: customer name or a permitted contact route used across appointments.
- Rule
- Use one authoritative customer-profile field where reuse is intended, then record which value was associated with each booking when operational history requires it.
- Watch for
- Copying the same concept into several custom fields creates conflicting customer records and unclear updates.
Booking-specific question
Example: an arrival note that applies only to one appointment.
- Rule
- Store the answer on the booking snapshot with a stable field key and the wording or version the customer saw.
- Watch for
- Saving only on the customer profile can leak an old answer into an unrelated future booking.
Conditional service question
Example: attendee count appears only for a synthetic group lesson.
- Rule
- Store the condition, applicable service, option identities, validation rule, and behavior when the condition later becomes false.
- Watch for
- A hidden required field can block submission, while a formerly visible answer can remain active after the customer changes service.
Reusable customer preference
Example: preferred language, when the business has a defined operational use for it.
- Rule
- Explain reuse, let authorized users review or update the current value, and keep booking-time meaning separate when historical context matters.
- Watch for
- A profile edit can silently rewrite the apparent meaning of old appointments if no booking snapshot exists.
Acknowledgment or sensitive intake
Example: arrival-instruction acknowledgment or a higher-risk intake answer.
- Rule
- Keep the exact wording, version, actor, time, applicable booking, access boundary, and approved retention rule; use qualified review before treating a checkbox as legal consent.
- Watch for
- A required checkbox, signature, or health-style field does not by itself prove informed consent, legal validity, privacy compliance, or safe access.
Inspect the complete worked field matrix
These invented fields show how purpose, type, applicability, record ownership, and downstream outputs fit together. They are a planning example, not collected customer data.
Identify the booking contact
- Definition
- Text · required
- Applies
- Every synthetic booking
- Stored with
- Customer profile + booking reference
- Allowed outputs
- Staff view and confirmation
Send the synthetic confirmation
- Definition
- Email · conditionally required
- Applies
- When email is the chosen contact route
- Stored with
- Customer profile + booking reference
- Allowed outputs
- Confirmation; excluded from calendars
Check synthetic group capacity
- Definition
- Whole number · required
- Applies
- Group lesson only
- Stored with
- Booking snapshot
- Allowed outputs
- Staff view, confirmation, export
Prepare for this visit
- Definition
- Short text · optional
- Applies
- In-person service only
- Stored with
- Booking snapshot
- Allowed outputs
- Staff view; blank stays blank
Choose an available message language
- Definition
- Stable option ID · optional
- Applies
- When translated messages exist
- Stored with
- Customer preference + booking snapshot
- Allowed outputs
- Message routing and export
Review field-definition and answer changes
Labels, translations, options, conditions, edits, integrations, exports, and disposal can each break a field after its first successful submission.
The label or help text changes
Keep identity and old meaning stableDo not rename the internal key. Version customer-facing wording where historical meaning matters, and keep the label and locale shown with the booking snapshot.
Options are added, reordered, translated, or retired
Store stable option identitiesMap display labels to stable option values, preserve retired values for old records, and never reinterpret an old answer because the visible order changed.
The customer changes service or an earlier answer
Re-evaluate conditional fieldsShow, require, clear, retain, or archive dependent answers according to an explicit rule; never leave a hidden required error or silently submit an inapplicable value.
Staff or the customer edits an answer
Record actor, time, and scopeState whether the edit changes only this booking, the reusable profile, or both. Preserve the original when policy requires it and update only approved downstream destinations.
The answer enters a message, calendar, automation, or export
Map blanks and sensitive values deliberatelyUse stable keys, documented formatting, permitted destinations, and explicit blank handling. Do not expose private notes or render undefined, stale, or untranslated placeholders.
Retention ends or a deletion request is approved
Apply one controlled disposal ruleIdentify every copy, snapshot, export, backup boundary, and dependency; record the decision and outcome without promising deletion or compliance that has not been verified.
Look for warning signs in a software demo
Rename, translate, hide, leave blank, edit, and export the same invented field. A well-presented form cannot prove record integrity.
Trace five fake fields through one booking, one edit, and one export.
A fair trial defines the expected record before touching a product, then compares the customer form, confirmation, staff record, edit view, and export without using a real person.
- Create five synthetic fields with stable keys, purposes, types, applicable services, required rules, translations, allowed viewers, destinations, edit rules, export columns, and disposal expectations; include one optional blank and one conditional field.
- Submit one synthetic booking, change an earlier condition, correct one answer, rename and translate one label, retire one option, and inspect the customer confirmation, staff/customer record, edit surface, calendar or message exclusions, and untouched export.
- Reconcile every value by stable field and option identity, booking, version, locale, actor, and timestamp; record missing, stale, duplicated, inaccessible, untranslated, overexposed, or unmappable results as limitations rather than product verdicts.
Keep the test fair
- Use invented names, contacts, services, answers, and identifiers only after staging, account, booking-write, export, edit, and deletion authorization is explicit.
- Do not enter health, payment-card, identity-document, child, legal-consent, confidential, or otherwise sensitive data into a trial merely to test a field type.
- Treat documentation and this matrix as preparation. A named product needs dated hands-on artifacts and qualified review before any capability, accessibility, privacy, security, retention, or legal claim.