Salla may fit a booking-based offer, but the decision depends on the complete booking journey, not the presence of a calendar. Start with what the customer reserves: a seat, session, room or employee's time. Then define capacity, confirmation timing, rescheduling, cancellation and payment-failure behaviour. These details determine suitability and implementation scope.
Do not commission a generic “services store” before distinguishing inventory sales from time-constrained resources. A booking may depend on an instructor, venue and equipment simultaneously. Product discovery and requirements can turn those dependencies into testable scenarios before a build is estimated.
What do native features establish?
Salla documents a booking product with day-based or day-and-time scheduling. Its current guide also separates bookings from ordinary products and specifies Saudi time as the available time zone. Recheck those constraints in the actual account before implementation. Salla's booking-product guide.
Begin with the native route and identify the real gap. A desire for a more attractive screen is not by itself a reason to build a separate reservation system. Equally, a scheduling control does not establish support for resources shared between different services or your particular rescheduling policy. Each important requirement needs evidence in a trial configuration.
Build a feasibility matrix before pricing
| Decision | Question to test | Why it matters |
|---|---|---|
| Reservation unit | A seat per person or exclusive use of the resource? | Prevents conflicting interpretations of capacity |
| Shared resources | Do services share a room or instructor? | Exposes appointment conflicts |
| Confirmation | When does availability reduce, and when do holds expire? | Connects payment state with capacity |
| Changes | Who changes a booking and handles price differences? | Defines customer and employee work |
| Cancellation | How are capacity and payment actions reconciled? | Avoids incorrectly occupied seats |
| Operations | Where does the supervisor obtain the attendance list? | Establishes operational usability |
Classify each row as supported and tested, configuration-dependent, app-dependent, or unproven. “Possible” is not a test result. If a launch-blocking requirement remains unproven, do not turn the quotation into an unconditional delivery promise.
Ask what evidence would change the decision. For a simple fixed workshop, a native demonstration may be sufficient. For shared-resource scheduling, the useful proof is an attempted conflicting reservation, not a screenshot of the settings screen. This keeps feasibility work proportionate to the risk.
Separate commercial policy from software behaviour
Who decides when registration closes? What happens when a participant is late? Can a customer transfer a place to someone else? These are business policies, not values the implementer should invent to complete a form. Obtain approved customer-facing wording and qualified review where applicable obligations or contractual terms require it.
Translate each policy into a practical test. If changes stop after a cutoff, how does the supported journey enforce or communicate it? If an employee handles changes manually, who receives the request and confirms completion? A bounded manual step may be reasonable initially, but it must be visible to the team and must not be sold as comprehensive automation.
Make the source of availability explicit. A spreadsheet, calendar and store cannot all be independently authoritative without a reconciliation process. Even if the initial solution is simple, someone must own exceptional cases such as an instructor becoming unavailable after customers have booked.
Worked hypothetical example: workshops
This scenario illustrates feasibility testing; it is not a delivered-project claim. A business offers a morning workshop and an evening workshop, each with eight places. Both use one room and one instructor. The merchant also wants to sell an optional physical tool kit with the booking. The requirement is not adequately described as “16 seats per day”: timing, resources and the transaction composition matter.
The team configures one workshop, fills the available capacity using an authorised test method, and checks another booking attempt. It tests cancellation, rescheduling and whether the supervisor can identify the participant. Capacity changes are compared with payment states rather than assumed to occur at a convenient moment.
The tool kit needs a separate decision because the current guide distinguishes bookings from ordinary products. A clear separate purchase or another verified route may be appropriate. The team should not promise a custom mixed basket simply because the merchant prefers one. The merchant reviews the effect of the proposed route on customers before approving it.
When does an app or integration make sense?
If the trial exposes a genuine native limitation, compare a process change with an app or integration. Name the missing requirement precisely: team-calendar synchronisation, attendance data in another system or shared-resource availability. “Connect everything” does not define data direction or ownership.
For API integration and development, verify actual support and permissions before building, and specify what happens when synchronisation stops. Two systems should not quietly treat the same seat as available because one has stale data. Having an API does not remove the need for an authoritative record and exception process.
Accept the operating model before publishing dates
Software quality assurance should cover full capacity, excluded dates, missing information, incomplete payment, cancellation, rescheduling and employee access to necessary records. Use a permitted test method and approved accounts and amounts. Do not create real bookings that confuse staff or participants.
Check both customer and supervisor perspectives on mobile in the intended language. Then document one of four outcomes: proceed natively, proceed with a verified dependency, change the process, or select another solution. Discovering a decisive mismatch early is more useful than concealing it until launch.
Common traps include accepting a calendar demonstration without testing capacity, treating policy wording as implemented behaviour, assuming checkout can be changed freely, and postponing cancellation tests until the first customer needs help.
Frequently asked questions
Is every booking business suitable for Salla?
No. Suitability depends on resources, capacity, payment, changes and operations. A booking product is a starting point for evaluation, not approval for every business model.
Can checkout be customised however I want?
That should not be promised before verification. Start with supported behaviour and identify material constraints before approving the design.
Can cancellation testing wait until after launch?
Not when cancellation is part of the operating model. Establish its effect on capacity, order status and the authorised financial process before taking customer bookings.
What should I commission first?
A requirement matrix and a representative trial covering difficult cases. That evidence makes the subsequent build proposal more specific and less assumption-dependent.
A useful next step
Prepare the schedule and approved capacity, change and cancellation rules. Request a bounded feasibility check within Salla store development before entering every future appointment.
Source
Reviewed 26 October 2026: Salla booking products. Reverify capabilities and restrictions during implementation.