Before you start
Bring the facts, not more tabs.
- A clear operating decision: online ordering, table reservations, service appointments, or a combination.
- The business’s real menu or service catalog, prices, hours, staff or table rules, and payment policy.
- Permission from the workspace owner to use modules included in the project’s delivery tier or cloud entitlement.
You will learn to
- Read CORE, AUTO, tier, requirement, and suggestion states correctly.
- Configure the data behind customer-facing components.
- Test the customer action and the resulting Backoffice record together.
- Avoid destructive module changes on an already-live project.
Choose the operating flow before toggling Modules
Similar-looking businesses can need different systems. Decide what a customer creates and what the owner must manage after it arrives.
- Use Online ordering when the customer selects catalog items and submits an order.
- Use Table reservations when a guest chooses a dining time against table availability.
- Use Appointments & classes when a client chooses a service, staff member, time slot, class, or deposit rule.
- Add Customers when profiles should be created from orders and bookings and used for future service.
Done when: You can describe the customer input, availability rule, payment behavior, and back-office destination for every module you plan to enable.
Open Modules and read the state before changing it
The panel distinguishes always-on foundations, modules required by page components, and optional capabilities constrained by the delivery tier.
- Open Modules in the left rail and confirm the Delivery tier shown for the project.
- Treat CORE as always included and AUTO as required by a component currently used on a page.
- Read a tier badge as an availability boundary, not a decorative label. In the browser product, server entitlements remain authoritative at publish time.
- Toggle only the modules the business has agreed to operate and maintain.
Done when: Every enabled optional module has a named business owner, real source data, and a place in the customer journey.
Respect requirements and useful suggestions
Naratake expands hard requirements automatically and may suggest modules commonly used together. A requirement is necessary; a suggestion can be turned off when the business does not need it.
- Online ordering requires Catalog and Payments and commonly suggests Customers.
- Appointments & classes requires Catalog and may suggest Payments and Customers.
- Table reservations can operate independently and may suggest Customers.
- After toggling a module, review any “Also turned on” message and remove only suggestions that are truly unnecessary.
Done when: The enabled module set has no missing hard requirement, and optional suggestions match the real operating plan.
Enter the operational data customers will use
A feature is not ready because its toggle is on. Its prices, availability, policies, and public components must all agree.
- For Catalog and Online ordering, enter categories, items, prices, options, tax behavior, pickup or delivery rules, and available hours.
- For Table reservations, configure opening hours, table inventory or capacity, available times, and confirmation behavior.
- For Appointments & classes, configure services, duration, staff shifts, slot rules, capacity, and any deposit policy.
- Use Components to place the corresponding customer-facing block, then use Actions on related calls to action.
- Return to Launch guide and resolve any empty catalog or business-hours warning.
Done when: A customer-facing block exposes only valid items or times and quotes the expected amount before submission.
Test Storefront and Backoffice as one flow
The critical proof is that a customer action produces the record the owner expects to manage.
- Open Preview → Storefront and complete a test order, reservation, or appointment.
- Exercise validation and empty states, not only the happy path.
- Switch Preview to Backoffice and find the test record under Orders, Reservations, or Appointments as appropriate.
- Move the test record through the available status flow and verify totals, customer identity, and requested time.
- Repeat the essential path at Mobile width.
Done when: The storefront submission appears in the correct Backoffice area with accurate details and can move through its operational status.
Change live modules as a data migration, not a design edit
Once a site is live, orders, customers, reservations, and appointments may exist in module-owned database tables. Turning a module off can make a later deployment request destructive schema changes.
- Before disabling a live module, export or back up the affected records through the supported workspace controls.
- Confirm that the business has stopped the flow and removed related page components and calls to action.
- Read the editor’s live-site warning completely and cancel when the data-retention plan is unclear.
- After an approved change, run the full Storefront and Backoffice test again before publishing.
Done when: No live operational module is removed without an owner-approved retention plan and a verified replacement journey.
Final check
Do not call it done until these are true.
- Every module maps to a real customer action and business owner.
- Requirements, suggestions, delivery tier, and server entitlement were reviewed.
- Catalog, schedule, capacity, pricing, and policy data are real.
- A Storefront action created the expected Backoffice record.
- Mobile and error-state tests passed before requesting a launch supported by the workspace.