KOA Messaging Center
A custom SMS platform that replaced a $2M/yr third-party vendor, designed and built end-to-end.

One vendor. Rising costs. Zero control.
KOA was paying roughly $2 million annually for Zingle, a third-party SMS platform their franchise owners used to communicate with guests. As Zingle raised prices and new FCC regulations approached that the vendor was slow to address, the case for building in-house became clear. Beyond cost, the existing tool had no deep integration with KOA's reservation system. Automations were clunky to configure, and franchise owners had no way to segment guests based on reservation data they already had. The brief was to replace Zingle entirely with something purpose-built, reservation-aware, and owned by KOA.
Design the whole system before building any of it.
Before a single line of code was written, the entire feature architecture needed to be defined: not just stage one, but how every subsequent stage would connect to it. I started with competitive research across CRMs and SMS tools, then facilitated requirements sessions with product owners, franchise owners, and developers to understand what was actually needed versus what Zingle had simply conditioned people to expect. Wireframes went through multiple rounds of iteration as technical constraints surfaced. Some of the more dynamic features (custom segmentation based on reservation data, conditional automation logic) required renegotiating what was feasible given how data was structured in K2. The design had to account for that reality without compromising the experience for franchise owners who would use it daily.
Core messaging interface with predefined guest segments. Get franchise owners communicating with guests as quickly as possible.
Custom message templates with dynamic fields pulling from reservation and campground data, reducing response time for common guest questions.
Franchise owners could define their own guest groups based on arrival date, departure date, site class, reservation status, and other reservation attributes.
Automated out-of-office messaging based on campground-defined operating hours, added between stages to address an urgent operational need.
Keyword triggers, reservation status changes, and scheduled sends with configurable frequency limits and send delays. The most complex stage, designed upfront alongside everything else and currently in active development.
A reservation-aware messaging platform, built and owned entirely in-house.
The Messaging Center launched as a fully integrated part of KOA's internal tooling, pulling guest and reservation data directly from K2 rather than relying on a third-party sync. Franchise owners can message guests individually or in bulk, build reusable templates with dynamic fields, create custom segments based on reservation data, and share templates or segments across multiple campgrounds they manage. Additional features include archiving, duplication, and cross-campground sharing of templates and segments, with the same capabilities rolling out for automations on completion.



What shipped, and what it moved.
- Replaced Zingle with a purpose-built solution that integrates directly with KOA's reservation system, enabling guest segmentation and automation based on live reservation data
- Built to meet incoming FCC compliance requirements that the previous vendor had not yet addressed, reducing regulatory risk across the organization
- Four of five planned feature stages shipped, with automations actively in development
- Adoption across operations has grown continuously since launch, with satisfaction improving as feature parity with Zingle increased through staged releases
There are a few things I'd approach differently with more runway. Tracking which segments franchise owners use most frequently and surfacing those at the top of the interface, rather than defaulting to most recently created, would reduce friction for owners who rely on the same segments repeatedly. I'd also give franchise owners the ability to color-code their segments during creation, making them easier to distinguish at a glance in the messaging interface. Both are on the backlog. The bigger architectural lesson was that designing the full feature set upfront before stage one was the right call. It prevented the kind of structural rework that would have been painful to retrofit into a live product mid-rollout.