Public roadmap
What is coming, and what is deliberately not here yet.
CampsiteOS ships a small product that works rather than a large one that nearly does. Everything below is real — some of it is built and waiting, some of it is a direction. None of it has a date, and we would rather say so than invent one.
Built, and waiting for a park that needs it
These work today and were taken out of the first release on purpose — a smaller product is a finishable one. They come back when a real campsite needs them.
Waiting list & cancellation offers
Why, and what it would be
The version worth building is short-fuse: a freed pitch goes to everyone who matches at once, the offer expires in a day or two, and the first to pay gets it. A queue that emails one person at a time and waits is how a July cancellation goes unsold.
Several parks under one login
Why, and what it would be
A park switcher, per-member access to individual parks, and reporting that adds them up using the same definitions each park uses alone. This was built and then set aside: we onboard parks by hand, and a group needs that hand ten times over before it needs software.
Winter caravan storage
Why, and what it would be
Storage is not a pitch booking — a caravan in the back field occupies no numbered plot and must never make one unsellable. It is a capacity count over a date range, with its own agreement, price and collection date.
Selling through the big camping portals
Why, and what it would be
iCal works today, in both directions, which is what stops a double sale when you already sell somewhere else. A live two-way connection is a different promise: it means naming a portal, standing behind that integration, and paying for the channel manager in between. It comes back for a park whose portal bookings are worth more than the connection costs — and it comes back to the portal that park actually uses.
Tour-operator allotments
Why, and what it would be
Blocks that release back to direct sale on an agreed date, and a manifest import that seats real named guests on the pitches held for them — with their nights counted properly for tourist tax, which is the part that is easy to get wrong.
Bank statement import
Why, and what it would be
Matching on the payment reference, with a guard against the same statement being imported twice — banks reissue them constantly. Deferred because matching rules that have not met a year of real statements quietly pay the wrong invoice.
Payout reconciliation
Why, and what it would be
You can already see what arrived and when. This is the line-by-line version your accountant wants: which bookings made up the payout, what the provider deducted, and what is left unexplained.
Public API & webhooks
Why, and what it would be
Publishing an API is a promise not to change its shape, and that promise is worth making once the data model has stopped moving. Your data is not waiting on it: Settings → Integrations exports the whole park — pitches, guests, bookings, invoices, the ledger — as one file, whenever you want it.
Booking widget for your own website
Why, and what it would be
Today you link to your booking page, which is your own address and takes no commission. A widget puts the same flow inside your WordPress or Wix page. It is a second copy of the most important screen in the product, so it comes back when the first copy is finished.
Texting your guests
Why, and what it would be
Written and tested, and switched off: no park has ever had an SMS provider connected, so no guest has ever had a text from us. It sends from the park's own sender name, not ours — and since March 2026 that name has to be registered per country, transactional messages included, which is the real work rather than the code. Until then the gate code reaches the guest on their booking page and in the offline guide, and the balance reminder reaches them by email.
Verified-stay reviews
Why, and what it would be
Collection, moderation with recorded reasons, your public reply, and the rating on your booking page and in search results. It was built and taken out: running public content is a job with an owner, and most parks already have Google and their OTAs. Quotes you choose yourself stay on the booking site meanwhile.
Guests changing their own booking
Why, and what it would be
One tap moves real inventory: it reprices the stay, checks the night is free on that pitch, adjusts the balance and reissues documents. Reception does all of that today, seeing every consequence. It comes back when amendment volume makes the automation worth its edge cases.
Ordering from your pitch
Why, and what it would be
Charged to the stay and put on the desk's delivery list. Extras chosen when booking already work; this was the separate in-stay catalogue on top. It needs a park genuinely set up to fulfil orders, not just a screen to place them.
Gift vouchers
Why, and what it would be
A sold voucher is a liability with its own life: a code, a running balance, part-redemption, expiry and breakage in the ledger. That is a small financial product, and it comes back when parks sell enough of them to be worth owning.
Severe-weather warnings
Why, and what it would be
MeteoAlarm publishes them; the work is owning coverage, freshness and what happens next. The evacuation roster went with it — it was only ever reachable during a warning. Both return together for parks in flood and fire zones, where a CPS procedure makes them a legal obligation rather than a convenience.
Certificates & renewals
Why, and what it would be
Country-suggested duties, recurrence, reminders at sixty, thirty and seven days, uploaded evidence and a binder to hand an inspector. A renewal tracker is a calendar with an evidence store; it returns when parks ask for it rather than because a country template exists.
Card dispute evidence packs
Why, and what it would be
A disputed card payment still shows on your money screens with its amount, its deadline and its status — that stays. What was taken out is CampsiteOS assembling the reply: your payment provider already does that in its own dashboard, and answering a chargeback in two places is how one gets missed.
A desk that works without signal
Why, and what it would be
Clicks held on the device and replayed on reconnection, with conflicts brought to a human. It was built and taken out because it is a second way for every write to behave, and the launch parks have reliable reception. It returns as a keep-and-test decision the moment a poorly connected site is a real customer.
Directions we are exploring
Not built. Named here so nobody has to guess whether we have quietly shipped them.
Certified invoicing in Spain, Portugal, Croatia and Slovenia
Why, and what it would be
Those four reserve invoice issuance to nationally certified software — VeriFactu, AT certification, Fiscalization 2.0, fiscal verification. Today CampsiteOS prepares the VAT, booking and payment facts and records the reference from your certified tool. Getting certified in each is a per-country project.
Business phone & missed-call recovery
Why, and what it would be
A portable number for the park, and a missed or busy call answering itself with one helpful booking link. Answered calls stay untouched. No call recording, no phone menu, no AI answering — those are somebody else's product.
A campsite email workspace
Why, and what it would be
Each park gets its own sending identity — never a shared mailbox across campsites — starting on a CampsiteOS subdomain and moving to your own verified domain. Connecting Google or Microsoft stays optional rather than being the foundation.
Asset & maintenance management
Why, and what it would be
Equipment, inspections, preventive schedules, parts, costs and downtime, from a desk or a phone in a field. This one waits for design partners: maintenance software that was not built beside real operators becomes a form nobody fills in.