Define what your site needs, give every supplier the same live jobs and choose software that fits the guest experience and the work behind it.
Give every supplier this same brief, then replace it with your real units and rules.
Map the units, stay patterns and operating jobs the software must own. Then run the same mobile booking, pricing, payment, amendment, arrival and export tasks with every supplier. Score demonstrated outcomes, full cost and migration risk—not the longest feature list.
Write down what the guest chooses and what the team prepares. A named treehouse, a three-pod grade and a seasonal safari tent need different rules.
For example: “The system must run direct and telephone bookings, prices, deposits, extras and guest records for nine glamping units; accounting remains in Xero and we do not require OTA connections at launch.”
Ask suppliers to demonstrate each area using your actual unit mix, dates and edge cases. A checked feature is not proof that the workflow fits.
The inventory model should match what guests choose and what the team allocates.
Test the real season, weekend and occupancy logic—not one perfect nightly rate.
The software should preserve the quality of the stay when the guest books on a phone.
Glamping revenue and fulfilment often extend beyond the accommodation rate.
Ask the team preparing the units to test the system, not only the person buying it.
A logo is not evidence of a working connection or a safe recovery process.
A guest profile is useful only when the data can be understood, used lawfully and retrieved.
The implementation, contract and service around the screen are part of the product.
Decide whether website, channels, payments, messages and operations come from one supplier or several.
Send the scenarios before the call. Ask the demonstrator to complete them live using a test site that resembles yours.
Record what was completed, what required a workaround, and which answer depends on another product or a future roadmap item.
Set the weighting before supplier demos. Score each criterion from 0 to 5, multiply by its weight and attach the evidence behind the score.
| Criterion | Weight | Score 0–5 | Evidence required |
|---|---|---|---|
| Inventory and operating dates | 15% | ____ | Named unit and grade scenarios are configured correctly |
| Pricing and stay rules | 15% | ____ | Weekend, midweek and seasonal totals calculate as expected |
| Direct booking journey | 15% | ____ | A suitable mobile booking completes without supplier help |
| Extras and payments | 10% | ____ | Extra, deposit, amendment and balance workflows are proven |
| Arrival and turnover | 10% | ____ | The operating team can complete its busiest-day jobs |
| Channels and integrations | 10% | ____ | Required live connections and error ownership are evidenced |
| Guest data and reporting | 10% | ____ | Required answers and usable exports are produced |
| Migration, support and cost | 15% | ____ | Written implementation, service and three-year cost are supplied |
| Weighted total | 100% | ____ / 5 |
Missing, unsuitable or only described.
Works with a material limitation or workaround.
Completed clearly with written evidence where needed.
Use the same units, booking volume, payment value and required channels for each supplier. Mark estimates separately from contracted amounts.
The current UK market presents several different commercial and product models. These examples were reviewed on 17 July 2026; verify every requirement directly before shortlisting.
Publishes tiered plans and describes direct booking, extras, payments and channel management.
Review public informationPublishes a subscription plus booking-charge model and names multiple channel connections.
Review public informationPublishes a small-site plan with a monthly fee plus a percentage per booking.
Review public informationDescribes unit-specific pricing, extras and deposit or pay-in-full controls for glamping.
Review public informationThis is not a product ranking. Feature availability, prices and terms can change, and similarly named integrations can behave differently. Record the date, source and demonstration evidence for every shortlisted claim.
Keydesk currently focuses on direct and booking-office reservations, a live calendar, operator-controlled pricing, deposits and balances, extras and guest records for independent accommodation operators.
Live OTA connections are not currently claimed. If Airbnb, Booking.com or another channel is essential at launch, record that as a constraint rather than scoring a roadmap promise as delivered.
Ask to see the workflow live from both sides of the booking.
Most sites need a reliable booking calendar, direct booking journey, pricing and stay rules, deposits and balances, guest records and usable reporting. Channel management, automated communications, housekeeping, accounting or access-control tools may sit inside the same product or connect separately. Define the boundary before choosing a supplier.
The best fit is the system that completes your real booking, pricing, payment and arrival workflows without unnecessary complexity or hidden cost. A small site should test its hardest stay pattern and busiest operating day rather than choose from a generic feature count.
It should be tested with the actual mix you sell: pods, huts, cabins, bell tents, safari tents, domes or lodges. Verify whether each unit is booked individually or through a grade, and whether capacity, facilities, operating dates and prices can differ.
Only if those channels are part of your distribution plan. Ask which named connections are live, whether availability, rates, restrictions and reservations move in both directions, how quickly updates happen and who owns support when a sync fails.
Calculate a representative three-year cost including setup, subscription, per-booking charges, payment fees, channel fees, website work, training, data migration and optional modules. Compare the same unit count, booking volume and required capabilities for every supplier.
Many systems can, but the workflow matters. Test availability limits, per-stay or per-night pricing, tax treatment, amendments, operational fulfilment and whether guests see an appropriate offer without making checkout confusing.
Agree the data scope and cutover plan in writing. Reconcile future bookings, payments, balances, guest details, notes and unit assignments in a test import, then run representative bookings through both the operator and guest journeys before going live.
Keydesk focuses on direct and booking-office reservations for independent accommodation operators, with a live calendar, operator-controlled pricing, deposits and balances, extras and guest records. Live OTA connections are not currently claimed, so sites requiring them today should treat that as a selection constraint.
Share your units, stay patterns and must-have workflows. We’ll assess how the current Keydesk product fits and identify any constraint clearly.
Be first to hear when beta opens. No spam. Just occasional updates as we build.