Skip to content

Go-live

Go-live is the moment CampOne becomes your production system. We pick the date closely with you — typically outside peak season, often February or March for the summer season, or October for winter. A well-prepared go-live feels almost boring: data is in, staff are trained, hotline is reachable.

One week before go-live the following are in place:

  • cutover date and time are set
  • staff are informed and have had a first training session
  • online widget is live on a test subdomain
  • existing bookings have been verified in the sandbox tenant
  • backup of the old system is at hand
  • emergency contacts are named on both sides

48 hours before go-live, CampOne sends you a pre-flight checklist with every item that needs to be green for the start.

The cutover usually runs in the evening (e.g. 22:00). Sequence:

StepOwnerDuration
Freeze old system (no more writes)You5 min
Delta export of latest bookingsYou15 min
Final import into CampOneCampOne30–60 min
Sample verificationJoint30 min
Switch online widget to productionCampOne5 min
Release email to your teamYou5 min

Total typically 2–3 hours. For large data volumes or complex configurations we plan a longer maintenance window.

Training happens either on cutover day (morning) or the day after, whichever your team prefers. We run a separate session per role:

RoleContentDuration
ReceptionCalendar, create booking, check-in/-out, TWINT, search90 min
BookkeepingInvoices, payments, dunning, VAT report60 min
ManagerReporting, rate changes, season comparison60 min
OwnerAudit trail, compliance, strategy45 min

On site, by video call, or hybrid — your choice. Recordings are made available afterwards so new staff can catch up later.

The widget goes live with a short transition phase:

  1. The embed code on your site is replaced — old solution out, CampOne widget in.
  2. First test booking by a team member (typically: bookkeeping books a fictitious family).
  3. End-to-end check: confirmation e-mail, guest portal link, TWINT payment, HESTA count.
  4. Release e-mail to your reception team — from now on everything is production.

The old booking system stays available read-only for about 7 days — in case anyone needs to look up an old confirmation.

For the first 14 days you have a direct line to our support:

  • Weekdays 8:00–20:00: response within 30 minutes
  • Weekends and holidays (relevant for camping): response within 2 hours
  • Escalation path for critical issues (payments blocked, HESTA report failing)

The hotline number is handed over at go-live. Save it directly in your reception tablets — faster than searching e-mail.

For the first 7 days we run a daily 15-minute video call to review:

  • new bookings — captured correctly?
  • incoming payments — matched correctly?
  • first HESTA daily values — do the numbers match your expectation?
  • audit-trail anomalies — any unusual activity?

Daily checks are the most effective measure against silent misuse in week one.

After 30, 60, and 90 days we run a structured review (60 minutes):

ReviewFocus
30 daysDay-to-day operation — what works, what’s awkward?
60 daysFirst reports — do the numbers look right?
90 daysStrategic adjustments — rates, add-ons, workflows

After the 90-day review you switch to standard support — tickets instead of hotline, with a clear SLA.

Despite all preparation, surprises happen. Common topics and our response:

IssueReaction
Online widget shows wrong availabilityImmediate emergency disable possible, fix within 1 hour
TWINT payment failsTickets straight to our payment partner, manual capture available in parallel
Wrong rate on confirmationWe correct manually, send a correction e-mail, fix the configuration
HESTA reports an errorCorrection in the next daily report — no penalty for timely fixes

Important: never tinker in the database directly — even if a staff member had database access historically, lock it down. Corrections only via the UI or via support.

  • channel manager activation (if planned) typically in week 3–4
  • dynamic pricing from week 6 (once enough booking volume has accumulated)
  • reporting routines from the first month-end close

These extensions are planned in their own onboarding steps — not all at once.

  • Use end-of-season timing. A go-live in October before summer planning gives 4 months to settle in before the system is at full load.
  • Have a fallback plan. Even if it’s never used, a clearly documented plan for working 24 hours without the digital system reassures the team.
  • Recognise your staff. A small thank-you — pizza on training day, a mention in the newsletter — makes the transition noticeably easier.