Technology & Operational Systems · The SHAC
Building Technology Around a Real Outdoor Operation
How The SHAC turned frontline operational requirements into a bespoke booking and management platform — and what years of live use taught us about technology, people and systems.
This is not a case study about writing software. Nobody at SHACADEMY built the system described here.
It is a case study about something more useful: what happens when the people running an outdoor operation understand their own problem well enough to describe what technology actually needs to do — and then work with a technical specialist to make it exist.
The system was developed collaboratively over several years and grew from a booking tool into much of the day-to-day administration of a busy outdoor operation. Its history is recorded in system documentation, a later technical review and the working records of the people who used it. Where that record is approximate, this page keeps it approximate.
Case study snapshot
At a glance
Organisation
Development from
Production system from
Scale
Operational contribution
Technical development
Testing & administration
What SHACADEMY evidences
Focus areas
- Operational Requirements
- Booking & Customer Journey
- Systems Thinking
- Working With Technical Specialists
- Operational Administration
- Reporting
- Technology Strategy
- Provider Neutrality
One
The problem was operational, not technical
The SHAC was growing faster than the arrangements holding it together. Bookings, staffing, participant details and what happened onsite lived in different places, and the tools available were not solving the problem the operation actually had.
Outdoor activity operations are unusually awkward to systemise. Sessions depend on water conditions, staff ratios, equipment, weather and daylight. Participants arrive in groups that change on the day. Medical and welfare information has to be accurate and reachable at the water’s edge, not filed somewhere useful only in an office.
The requirement was never “we need software”. It was a set of operational problems that kept recurring, and which conventional booking arrangements were not adequately answering at the time.
Two
Requirements came from the operation, not a software brief
Skip initiated the project from the operational side and originated much of what the system needed to do, working from daily frontline use.
That is a different discipline from software design. It means noticing which questions staff keep asking, which information keeps getting re-entered, where customers hesitate, and which parts of a day consistently create avoidable administration — and then describing those problems clearly enough that a developer can build against them.
Development happened progressively, in response to the practical needs of the business, rather than from a single finished specification written at the outset. Requirements arrived as the operation met them.
The best operational requirements are written by the people who have to live with the answer.
Three
Designing around how the operation ran
The calendar logic at the centre of the system was originally designed by Julie Willard to streamline how The SHAC actually ran, and the customer-journey logic grew out of the same operational thinking.
That work matters more than it might sound. In an activity business, the calendar is the operation: it decides how sessions are structured, what a customer sees as available, how activities are filtered and how a booking becomes a staffed, equipped session on a specific piece of water at a specific time.
The system evolved from operational input led by Skip and Julie, with different ideas and requirements emerging from the practical running of The SHAC. It was collaborative from the beginning, and no single person designed all of it.
Four
Translating requirements into software
Operational requirements were translated into working software with Bryan Butterworth / Cloud Business Systems, who led the technical development and implementation.
The technical contribution was substantial. The system documentation produced alongside it records a genuine production platform with a wide functional footprint, not a lightly customised booking widget.
It is worth being precise about this, because the temptation in a case study like this is to blur the line. The SHAC specified, tested and lived with the system. The software engineering was done by a professional developer, and the credit for that belongs with him.
Five
Testing before it reached the operation
Matt tested development work before it reached the live operation.
In a live outdoor business that is not a formality. A booking flow that fails on a Saturday morning does not produce a support ticket; it produces a queue of families at a lakeside, staff improvising and a session that starts late.
Having someone inside the operation checking development work before release was one of the quiet reasons the system could keep changing while the business kept running.
Six
Real-world use at scale
Informal versions and early development are recorded from around 2020, with a production system from approximately 2022. Those dates are approximate and are deliberately not stated more precisely here.
By the time of the later technical review, the system contained more than 27,000 customer accounts.
That figure is a measure of accumulated records rather than of active or annual customers, and it should be read that way. Its significance is simpler: this was a genuine production system, deeply integrated into the running of the operation, rather than an experiment that never left the office.
Seven
From booking tool to operational platform
What began around booking progressively expanded into much of the administration of the operation. Not all of this existed at the start; functionality accumulated as the operation asked for it.
Documented functionality developed across areas including:
- customer accounts
- activity and session booking
- complex pricing
- vouchers
- attendee and participant information
- medical information
- staff scheduling
- onsite operational and check-in functionality
- participant identification, including band and hat number recording
- customer communications
- payments
- operational administration
- reporting
- supplier and administrative access
Recording participant identification onsite — band and hat numbers and similar operational records — was part of the system from early in its operational life, and that experience later informed continued interest in participant-identification technology.
Eight
Refinement driven by daily use
Systems improve in the hands of the people who use them every day. Lynda’s operational administration — tailoring booking confirmations, website updates and financial reporting — put the system under the kind of sustained daily use that surfaces what documentation never does.
Reporting responsibility was shared with Skip, and that combination of frontline administration and operational oversight is where a steady stream of issues, gaps and practical refinements came from.
It is a pattern worth naming, because it is repeatable: the person doing the administration is usually the best source of requirements an organisation has, and the easiest one to overlook.
Nine
What came afterwards
Cloud Business Systems subsequently developed Take That Booking, a separate commercial booking platform whose deployments use a related codebase and retain operational patterns first developed and tested through The SHAC system.
That evolution is an interesting legacy for the project: ideas shaped around the practical requirements of one outdoor operation went on to inform technology deployed beyond it.
Ten
What worked, and what proved harder
What worked, in this project:
- technology designed around real operational requirements rather than an abstract specification
- functionality that could evolve through frontline use
- customer booking and operational administration connected in one place
- staff and operational teams able to feed practical requirements into development
- bespoke development addressing needs that generic booking products were not necessarily solving at the time
- a system that reached genuine operational scale rather than remaining a concept
What proved harder is the part that rarely appears in a software case study. Once a business depends on a system built specifically for it, a set of long-term questions becomes unavoidable: ownership, documentation, maintainability, portability, supplier dependency and how the technology strategy will hold up over years rather than seasons.
None of that is an argument against bespoke development. It is an argument for going into it with those questions already answered.
Eleven
What this means for SHACADEMY's technology position today
Years of specifying, commissioning, operating and reviewing bespoke technology produced a more mature position than simply advocating building your own:
Understand the operational problem first. Connect where possible. Build where necessary.
SHACADEMY is deliberately provider-neutral. It is not a software house, a booking-system developer, a CRM developer or an ERP developer, and it does not sell software development.
The capability this experience evidences is narrower and more useful than that:
- understanding how an outdoor operation actually runs
- determining what technology genuinely needs to do
- evaluating the systems already available
- communicating requirements clearly to technical specialists
- understanding the operational implications of technology decisions
- identifying when connecting existing technology is the better answer
- recognising the narrower cases where bespoke development is genuinely justified
That is why SHACADEMY’s current technology work starts with the operation and treats software as the last question rather than the first.
Where this experience applies
Related SHACADEMY work
Technology & Operational Systems
Independent, provider-neutral advice on the systems that run an operation — understanding the problem first, making the most of capable existing systems, and building only where a genuine gap remains.
Explore →The SHAC
The wider story of the organisation this system was built around — how it grew, how it operated and the systems thinking that developed alongside it.
Read the case study →Start a conversation
Working out what your technology actually needs to do?
If your operation is running on systems that nearly fit, the most valuable work usually happens before any software is chosen.
Understand the operational problem first. Connect where possible. Build where necessary.