Core objects
The initial model centers the booking as the shared operational record. Object names and fields remain subject to pilot feedback.
Booking
Section titled “Booking”Holds the service date, party, commercial status, supplier status and next operational action. A booking should remain legible from enquiry through completion or cancellation.
Customer
Section titled “Customer”Represents the minimum person or party context needed to manage the booking and the next useful conversation. The product direction avoids collecting data merely because a generic CRM normally does.
Supplier
Section titled “Supplier”Identifies the party expected to confirm or deliver a service. Supplier references and confirmation state belong to the workflow and must remain traceable.
Product and service
Section titled “Product and service”Describe what was sold and what must be operated. Future pilots will define how much catalog structure is useful without forcing every operator into the same inventory model.
Operational task
Section titled “Operational task”Represents a concrete next action, owner and due state connected to a booking. It should explain what is incomplete rather than inflate a task counter.