Campground Automation Systems

You’ve heard us mention it…

It has been a busy Winter season for us, and we’ve been cranking out some great new features while we try to keep up with all the new park signups. But I promised in December to continue our technical blog with some details about our business rules engine, and I think it’s high time I do.

If you’ve ever spoken with one of us at one of the industry trade shows, you’ve heard us mention our “powerful business rules engine” at least once. We’re very proud of it. It is a core part of our system and it allows us to fit our software to the specific needs of each Campground. Sometimes, however, when we speak about it we either “geek out” a bit or gloss over it such that the true impact of the technology is lost. Let me try to explain just what all this means to campgrounds…

Fundamental truths and new technologies

A fundamental truth of all software is that it is only as flexible as it is written to be. Seems obvious, right? The question, “Build or Buy?” is based on this truth. Most people can’t afford to build their own software, or don’t know where to start, so “Buy” is the default answer for many, leaving software developers to identify a need and attempt to meet that need as broadly and flexibly as possible. Well, there are many methods we developers use to build flexibility into our software, and most software you use offers some way to alter the behavior of the application to suit the user. But as users, we’ve all experienced the confining frustration of finding the limits of a given piece of software. Like a ill-fitting piece of clothing, we are uncomfortable “wearing” software that just doesn’t fit.

When we set out to build our real-time reservation/campground management software system around our self-service kiosk and wireless utility control platform, we started looking at what software developers call the “problem domain”. That is, what do campgrounds and RV parks need their management software to do? What do they all have in common? What don’t they have in common? These are the questions every other vendor has asked themselves as they’ve built their products. What we identified early on, and it may seem like another no-brainer, is that no two campgrounds are just alike. Sure, many campgrounds operate in similar ways, and it is the overlap that allows us to build the bulk of our software logic to work consistently for all users. But what of the dissimilar ways in which parks operate? How do you address those?

In our case, we built our solution using an advanced software framework known as a Business Rules Management System (or BRMS). BRMS’s are often used in high-availability software systems involving complex financial scenarios often found in banking or insurance. While our needs are perhaps more modest, this demonstrates the power at our disposal. The more important thing, perhaps, is that this technology allows us to individualize the “business rules” of our campgrounds in two key areas, rating and site availability. Using our custom rules engine, then, we can establish an individual “rule set” for a given campground and deploy that rule set into our running application at any time, instantly altering the behavior of these two key areas. The benefits here should be obvious; we don’t need to make changes to our applications’ logic, which further bloat the software and restrict flexibility and future development. And this is why we have such a diverse group of parks using Sunrise — small, unattended parks, to large, multi-campground membership organizations with highly complex business rules.

Of course, the power and flexibility this technology affords us would be mostly useless without also having an expressive and elastic underlying data model. If you hear us talk about a “data model”, what we’re referring to is the way we’ve defined and connected things like “Reservations”, “Invoices”, “Guests”, “Sites”, “Amenities”, “Memberships”, “Vehicles”, etc. And when we describe ours as “expressive”, we’re referring to just how much data we collect for each of these items and how closely each are related. Our expressive data model allows us to define potential “facts” in a given reservation scenario and “grab onto” these facts while processing rates or determining which sites should be made available for booking.

So where do the rules fit in?

Our rating rules are engaged prior to booking a reservation, (to provide a real “estimate”) upon booking a reservation, (to create a new invoice and assess actual charges) and any reservation edits that might influence rating. (extending/shortening stay, adding guests, cancellation, etc.) This functionality is available in both Panorama and SunriseReservations.com, though reservations processed through either can have individual rating rules applied. (ie: assess additional fee for online reservations) Our rating rules handle guest discounts, taxes, weekly/monthly rates, surcharges, etc.

Our site availability rules are engaged whenever a user searches for available sites for potential booking. (but can be bypassed by managers) This acts as a sort of filter, further filtering the list of available sites after availability is first determined by looking at already booked sites for a given search criteria. This allows “available” sites to be further limited by any of the “facts” in a given case. Examples include restricting non-members from booking particular inventory, or limiting the visible online inventory to a percentage of actual available inventory.

Experience bolsters confidence

We like to say that we can make the system do almost anything, and we’ve certainly been tested on that point! Our experience has validated, not shaken, our confidence, however. If you can begin to imagine for yourself how access to information about a guest and their memberships, vehicles, occupancy requirements, previous reservations, preferences, etc. would be useful in determining both their rate and access to site inventory, you may be confident, too. This post could grow indefinitely if I were to provide further examples, so I’ll only mention one more possibility — Yield Management. You may define this in any number of ways, but however you do, the ability to establish rates based on capacity, etc. should be appealing.

I hope this has helped to explain not just how powerful and flexible our rules engine is, but at least a little of how it actually works. If you’re not a Sunrise customer, I hope you see the possibilities of this technology, and contact us to learn more. If you are a Sunrise customer, I hope you’ve gained a greater understanding of the technology you use each day and perhaps sparked an idea or two. We’d love to talk with you about your ideas. We get great satisfaction out of building new rules for parks that can help them be more efficient and in turn, more profitable.

Author

Jon

Category

Development

Comments

0

Kicking off our Development Blog

On behalf of our development team, I’d like to welcome you to the new Campground Automation Systems Development Blog!  And along with that welcome, I’d like to take the time to provide some history here and explain what to expect from future posts to this blog.  You see, we’ve been just crazy busy for some time now.  And while the we’ve been able to share much of the fruits of our labor with the world, we wish to share more of the truly exciting aspects of our work.

This new development blog will allow us to share some of this excitement we as software developers and engineers feel as we build innovative technology solutions for campgrounds and RV parks.  We hope to describe in greater detail these solutions to some of the unique challenges we and our customers have faced.  You may also expect to get sneak peaks at upcoming features and catch glimpses of the underlying technologies we use to build great products.  Our hope is that this information will be a benefit to our customers and to those not yet Sunrise users.  We also hope to provide a service to the wider Java/Open Source developer community of which we are a part, by sharing some of our experiences.

As CTO and Senior Engineer, I take pride in our fine development team.  Each member is passionate about technology and dedicated to the user experience.  You can expect to see posts from each of them here, detailing aspects of their current projects and sharing their expertise.

In order to wrap this post up on a somewhat technical note, I’ll attempt to briefly describe something that is core to our system — real-time reservations.  As we set out to develop a software back-end for our self-serve outdoor check-in kiosk system, we knew that our system had to be real-time.  That is, the inventory managed by the system, and available from a remote kiosk needed to be accessed in real-time in order to know for certain that sites were truly available and to prevent double-bookings.  We also planned to provide a complete, “end-to-end” system, with a powerful guest-centric online portal site.  These requirements meant developing a fully web-based management system, backed by a robust transactional database system, deployed to the so-called “cloud.”

Over the past several years, we’ve done just that, and it has resulted in a powerful, flexible and scalable platform with many features built on top of our real-time inventory model.  In future posts, I hope we can share more about this platform and why we feel Sunrise truly is “A New Day for Campgrounds.”

Author

Jon

Category

Development

Comments

0