Windsurf · Wingfoil · Kite · Surf · Dive
Run the whole centre, and own the whole guest relationship. Four applications on one database — booking, the desk, the beach and the guest’s own phone — so every lesson your coaches teach becomes progress the guest can see, and a reason to book again.
4
Applications, one database
1
Guest record, booking to bill
2
Sports live, more by configuration
0
Servers to run
System design · two and a half minutes
The film follows one booking through every hand-off the operating day makes: intake into operational records, the desk opening the stay, the beach delivering and grading the service, the guest’s app reflecting it, and the bill reconciling without anyone reconciling it. It is the system design, shown on the production screens rather than drawn as a diagram.
What most centres run today
A booking platform the centre does not own. A spreadsheet for the board fleet. A paper lesson book. A chat group on somebody’s personal phone. A till that knows nothing about any of it. Every guest is typed in more than once, and the season’s real numbers only appear in October.
What SurfOps is instead
Four applications that are all reading and writing the same guest record.
They are separate because a wet phone on a beach and a keyboard at a desk are different jobs — not because they hold different data. Every guest exists once, however they reached the centre, and every charge is written against them automatically as it happens.
One booking, four applications
Direct from the marketplace or the guest’s own phone — or from a platform, through the same intake.
Named guests, a board, a storage slot, prepaid hours. Nobody re-types anything.
Lessons taught and closed, hours counted, kit issued, progress graded on the beach.
Every service already a labelled line on the right guest’s bill, settled at check-out.
The platform
A centre serves four audiences in four places: the open web, the office, the beach and the guest’s pocket. Each surface is built for its moment — and because they share one database, there is nothing to synchronise and nothing to reconcile.
Booking engine and white-label tour operator
A booking engine the centre runs as its own: a destination page with live wind, how many days of the week have historically been sailable, the coaches and the ratios. The copy, the hotels and the prices are self-administered — no developer to book a change. Live and taking enquiries today; the checkout, availability and payment are the next slice, so bookings are confirmed by hand for now.
Operations and logistics
The desk and back office: arrivals, the board fleet, storage, lesson planning, the shop and till, the bill, pricing, staff, reports and compliance. This is the system of record the other three write into.
The team app
Instructors and beach staff on their own phones. PIN sign-in, built for sunlight and wet hands, and offline-first so a weak signal at the far station delays nothing. Lessons, attendance, progress, rental hours and the team’s own feed.
The customer app
The guest’s own phone: conditions, what is on today, booking a taster, and — since August 2026 — their own diary of every session, hour and level. It carries the centre’s identity, not a marketplace’s.
Where something is planned rather than shipped, this page says so. The screenshots throughout are the production system as it runs today.
Centre OS
Arrivals, kit, people, hours, money and the record that proves it — the working system behind a centre that serves hundreds of guests a week and settles every one of them.
Arrival day
Platform bookings, agent bookings, guest-web orders and self-registered walk-ins land in the same list seven days out, each row carrying its channel, its pre-booked services and whether that guest has registered yet. Cancelled orders clear themselves, so it is always today’s work rather than history to scroll past.
The desk
Board, cover, lesson placement and registration handled with the guest standing there. One press opens the stay and activates every pre-booked line at once — and it goes through even when something is outstanding, so a family off a long flight is never held at the desk by an open detail. What is missing stays flagged on their row until it is resolved.
Registration itself happens on the guest’s own phone, from a QR code — their details, emergency contact and liability acceptance. The email and mobile they enter becomes their guest-app sign-in, which is how a booking made on somebody else’s platform turns into a contact the centre owns.
The fleet
Each board is one serial-numbered object with a model, volume, year and quality grade, laid out on a single calendar. Boards are pre-allocated automatically when bookings sync, and a guest who paid for a specific model is never quietly moved to a substitute.
Lessons
A course arrives as prepaid hours. Turning them into sessions is a judgement about language, ability and group mix — so the screen ranks every waiting guest against the calendar by language match, overlapping skills, precise level and soonest start.
Safety, live
Rentals out, lessons in progress and open hourly sessions combine into one timeline, longest-out first, refreshing every thirty seconds and colour-banded by time out. At close of day, one action brings the whole operation home — every open rental returned and billed, every session closed, every exception named.
The shop
Almost every centre sells something, whether that is a rail of clothing or a wall of hardware. Each item is catalogued by brand, category, size, colour and year, and selling one is what counts it down — stock is never typed over, so the shelf figure is a by-product of the day’s trade rather than a stocktake. The till will not sell past the count, anything not stocked rings up as a one-off line at the price agreed, and a sale takes cash or card at the counter or goes onto the guest’s bill alongside their lessons and kit.
The money
Nobody types a bill. A lesson joined, a rental sold, a storage slot, a shop sale, insurance, a surcharge — each writes one labelled line against the guest who incurred it, the moment it happens. Families roll up to one payer while every member keeps their own lines, and prices snapshot at the moment of sale so last season’s invoice always verifies.
The numbers
End of day per station, shop takings by month and year, open bills, commission payouts, credit vouchers, discretionary discounts, daily-ops compliance and the audit log — every one built from the same records the desk works in, so the operational picture and the financial one cannot disagree. Prices are the centre manager’s own: product, channel, season band and size, edited on screen and effective immediately across every till and sale.
TeamOps
Everything a centre knows about a guest is created twice: once at the desk, and once on the water by the instructor who taught them. TeamOps is the second half — and it is what turns a week’s holiday into a coaching relationship.
The paper lesson book, the whiteboard, the daily photograph of the whiteboard in a group chat, and the end-of-week transcription of all three into a spreadsheet. The record is captured once, by the person who was there, at the moment it happened.
A season’s worth of team knowledge stays with the centre instead of leaving with a personal phone number. And guests rate six things separately — instruction, equipment, service, the spot, conditions and travel — so a guest who loved the coaching but struggled with the kit is telling the centre exactly what to fix. It arrives the same day, while they are still in resort and something can still be done about it.
The guest app
A guest arrives for a week and leaves with an app that keeps them connected to the sport, the conditions and the people. It carries the centre’s identity, and everything in it comes from the same records the desk and the beach are working in.
Water time and lessons merge into one timeline the guest adds to — stars, the rig they sailed, and private notes only they can read. Shipped August 2026.
Guests fill in the registration form themselves, on their own phone, from a QR code — their own details, entered once. A taster or private lesson is booked without creating an account.
During a stay the app shows prepaid lesson hours as a running balance — four of six used — read from the same package record the desk works in, and updated the moment a lesson is attended. Rental hours the same way, per package.
Designed and not yet shipped: allocation confirmations and schedule-change notices by app and email, so the desk stops relaying messages and the guest always holds the current plan.
Why it compounds
Windsurfing and wingfoiling are learned in steps, over years, usually at more than one centre. The centre that can show a guest exactly where they are and what comes next is the one they come back to — and the one whose next sale is a welcome suggestion rather than a pitch.
Where it starts · thirty seconds on the beach
Coming off the water, the instructor grades the manoeuvres that were actually taught against the centre’s own catalogue, and awards the level. It is deliberately the shortest screen in the product — anything longer does not get done with the next group waiting, and then the record never forms at all.
Because every coach grades the same catalogue at the same level, a level means the same thing across instructors and across seasons. What the centre intends to teach and what it certifies are defined once.
Where it pays · the same afternoon
That single grading moves the guest’s level in their own app, and the next level appears underneath it with the sessions that teach it and a way to join one. The desk sees the same shortlist of guests ready to progress. The upsell became something the guest was already looking for.
The crossover is a priced product rather than a favour: a guest moving between windsurf and wing buys one Multisport package — one price, one bill line, both sports covered for the window.
Where it compounds · next season
A season ends with one clean guest list segmented by sport, level and what each guest is ready for next — not a spreadsheet of email addresses.
The same records measure the product itself: which lesson types fill, which levels stall, which instructors move guests up the ladder. And because the centre keeps its own guest identity rather than borrowing a platform’s — matching on email, then phone, then name with date of birth and country, with anything inconclusive going to a review queue — the list improves every season instead of degrading. A repeat guest who books direct next year carries no platform commission, so the centre keeps the full value of that booking.
Built for teaching centres
A teaching centre has obligations a rental shack does not: a certified progression to grade against, qualified staff to roster, safety routines to evidence, and a guest list in five languages. Those are the parts of the operation SurfOps was built around first — which is why the same system fits a windsurf school, a kite centre, a surf camp and a dive centre, whether the ladder it teaches is RYA, VDWS, IKO, PADI or the centre’s own.
Running today at a windsurf and wingfoil centre. The parts that differ between sports — the equipment catalogue, the lesson products, the level ladder and its manoeuvres — are per-centre data, so a dive or kite operation is configured rather than rebuilt.
The manoeuvres that define each level are per-centre data rather than code, so your ladder is loaded at setup instead of built. The model holds six levels in three bands; a progression shaped differently is a change we scope with you.
Safety routines are ticked off on the daily ops board by the person who did them, with missed and late jobs visible and a named end-of-day sign-off. The completion record is a by-product of running the day, not separate paperwork.
The lesson picker only offers instructors certified for that sport and level, and double-booking is prevented in the interface and again in the database — for every application.
Lessons match guests to instructors by language, and each centre’s seasons, prices, caps and date format are its own configuration.
Menu, reservations, orders, accounts and guest ratings are built in and role-gated to restaurant staff, so food and drink sit on the guest record rather than a separate till. Ready to pilot — it has not yet worked a live service.
Managed cloud with point-in-time recovery. No server in the office, no version to upgrade at the start of the season, no on-site installation visit.
Underneath all of it, the system audits its own records continuously — charges raised for a guest whose stay was never opened, guests who departed with an open balance, boards still to assign, duplicate guests, stays without an end date — and presents each as a worklist with the resolution one click away, so the data a centre certifies against stays clean through the season.
Who builds it
SurfOps is made by Syndeo, a product and delivery consultancy. The difference you can feel in the product is not a feature list: it is that the people who built it work inside a working centre, and that changing it afterwards does not arrive as a quote.
Syndeo is a product and delivery consultancy. SurfOps is our own product, built to the same standard as the platform work we do for clients — specified, reviewed, tested and released against real operations rather than a wishlist.
Every screen in SurfOps was designed alongside the people who use it — the front desk, the beach team, the centre manager — in daily use at a working centre since June 2026, through its first live season. It is not a generic booking tool with watersports labels on it.
Implementation, tests and the response to failures run as an agent workflow, while design, test and release stay gates a person reviews and signs off. That is why a request from the front desk is live in days rather than quoted as a change order for next season.
Improvements are raised from inside the app, on the screen where the idea occurred, and land directly in the delivery backlog. The operation shapes the product continuously.
The cost of changing the software stops being the reason a centre cannot change how it works.
There is no server to install and no version to upgrade at the start of the season — the four applications are hosted and update themselves. Standing a centre up is work we do with you and scope before you commit; after that, a change to how the centre works does not arrive as a change order.
More about how Syndeo works — syndeo.cz.
Where this goes next
In designThe same approach that builds the product is the direction the product itself is heading: intelligence sitting on top of a complete, live record of the centre — finding the improvements to service delivery a busy team has no hours to look for, and adding operational capacity that could not realistically be taken on any other way.
Unsold seats for the week ahead, guests who are ready to progress and leaving on Saturday, kit that is never issued, safety jobs slipping, a bill that will walk out of the door — surfaced as work with the resolution attached, rather than a dashboard someone has to remember to read.
The intention is to ask the season’s own data a question in plain language and get an answer — designed so identifying guest details are not part of the question, and every decision stays with a person.
The analysis, follow-up and continuous tidying that a centre knows it should do and never has the hours for — done continuously, and improving service delivery rather than adding headcount.
This is the designed direction, not a shipped feature. The foundation it needs is already in place: one database across all four applications, an append-only audit trail, and a registry of data-integrity checks the system runs against its own records.
Talk to us
The quickest way to judge SurfOps is a walkthrough of a live centre’s operating day — arrivals, the fleet, the water, the bill — and then the same walk through your own.
What a centre gets