Service buying needs a different handoff
A service-only cart does not need to behave like a parcel checkout. The inspected storefront uses a booking-details step for service items, with the merchant's required contact fields and a preferred date and time for each service.
Make the timezone and confirmation boundary visible
The time input is labelled IST and refuses invalid or past times. The interface explains that the merchant confirms the slot when accepting the booking. Keep that language in your customer process: choosing a preferred time should not be represented as a guaranteed reservation before the relevant confirmation.
Prepare service information that answers real questions
Explain what the service includes, its duration where applicable and the genuine cancellation terms. Do not use a physical-product stock number as a substitute for staff availability. A request form collects intent; it does not by itself establish a resource calendar or eliminate scheduling conflicts.
Evaluate the whole service workflow
Use a representative service and inspect the request details, merchant handling and customer follow-up before advertising instant booking. This page does not promise calendar integration, automatic slot capacity, venue reservation or every mixed-cart combination. Confirm the specific workflow you need in the current deployed version.
UNDERSTANDING THE WORKFLOW
Service-request details should not be mistaken for a confirmed appointment
Collecting information about a service request can help the merchant assess it. It does not necessarily mean a time slot has been reserved or the work accepted.
What the source establishes The inspected storefront includes a dedicated service-booking step. That is evidence of a service-related checkout surface. The title of a component is not enough to claim calendar synchronisation, real-time capacity checks or guaranteed appointments.
Describe the information requested in terms the merchant can actually fulfil. If a customer provides a preferred time, explain whether the merchant must confirm it. Keep this separate from a promise of instant booking.
Evaluate with a real service shape Use an authorised test case reflecting the details the business needs, such as the requested service and scheduling information. Inspect how those details appear for follow-up. Do not submit a live request merely to obtain a screenshot without permission.
State the boundary A request form can organise an enquiry while leaving acceptance and scheduling to a later workflow. Marketing should not erase that distinction.
The service-request feature page owns this capability. A stronger booking claim should wait for verified end-to-end behaviour, not be inferred from a field or component name.
Bring this checklist to your evaluation
- Service scope explained
- Preferred time labelled correctly
- Merchant confirmation process
- No unsupported instant-booking promise
Check the workflow that matters to your business
Read the relevant setup and troubleshooting guide, then explore getting started with oBizee. Confirm current account availability and terms before committing.