Reservation Systems

Skip on down further for some product example screenshots, or read below for a brief origin story.

Setting the stage: Clubessential's role in the golf, resort and club industry

Clubessential's market in the golf and member club industry was niche with only a few main competitors, yet the expectations were high because we worked with clubs where members would pay $20k-$100k and up to join (sometimes even after being on a waiting list for many years or by invite-only). The end users I spoke to were politicians, industry leaders, CEOs and even a 4-star General. Spoiler: the feedback was often direct.

Our overall market share was small when I started and we had few large or prestigious accounts that are key in such an industry based on relationships. Over time I played a vital role in winning many strategic accounts by traveling onsite for installs and saves, and collaborating with users, development and executives to manage the product roadmap, backlog and create user stories, wire-frames, field-test the updates, etc. I've been fortunate to be invited to some of the most private places in the US, and been in many high-pressure situations. One such example was when myself and an Account Manager traveled to Florida and went head-to-head with the market leader, with each company doing back-to-back pitches to the club's board on the product features and user requirements, and we won!

Eventually we became an industry leader, merged with a competing company to establish a broader product offering and market penetration and later sold to a private equity firm. But that is a whole other story. For now I want to give a simple example of what solidified my love for managing and developing a product, and proved my chops in such a role.

I fell in to a Product Manager role in 2012 when the right opportunity presented itself to redesign the front-end of Clubessential reservation systems.

At the time I was a Project Manager, with 50-100+ active SaaS installs in progress at any given time, and had the primary responsibility of onboarding clients with training and configuring their reservation systems. Every install was different. The product has a highly configurable rules engine to ensure the many different classes of memberships (or user types) were able to book at the right days and times, with the right amount of advanced notice, and with the right number of guests, golf caddies, rental clubs, etc.

My first opportunity to shine on the product side came shortly before the biggest conference in the industry, the PGA Show in Florida. We were set to release the 2.0 version of the product that came with the 1st-ever drag and drop capabilities on the administrator side. There was certainly a buzz in the air because this feature addressed a real problem: that reservations fluctuate constantly throughout the day yet most systems are difficult to make the necessary changes quickly, accurately and wide-spread.

I too was excited but, taking a holistic view and focusing on what was the key goal and biggest problem rather than the latest new feature, I knew that the end-users (the club members) still had an outdated UI. The developers built a highly flexible back-end, but had yet to pay much attention to the front-end.

It's important to back up any ideas with data. In this case my hypothesis was validated by direct feedback from both administrators and the end users that I gathered while conducting onsite trainings and interviews.

So, being a person of right action and also seeing a possible low effort, high impact update, I took the initiative and spent the weekend reworking the front-end on our demo site, learning new HTML and CSS along the way. It's important to note I also reached out to Design but no one was available to work on anything else. So on Monday I showed my boss (the VP of Sales and Product) what I came up with.

My boss immediately saw the value of the redesign, ran it by the executives, and that week we used the new code at the PGA Show. We also applied the updates for all new clients. Even some old clients saw the updated UI at the PGA Show and made unsolicited requests for the upgrades. It was a smashing success and right when sales really started to take off!

From then on I continued to play a central role in managing the product and adding new features, such as responsiveness, tablet functionality, APIs with other vendors and even after the horizontal merger to move more in to the Accounting and POS side of operations.

Okay, that's a lot of words. How about some examples?

Further down are just a few key examples of my work on tee sheets (golf reservations), but we had more than 1,110 installs and built systems for many other use cases, such as the following:

• dining at the exclusive and elusive Disney Club 33,
• tennis all over Florida,
• spa in Colorado,
• horseback riding in Texas,
• beach spots in California and Hawaii,
• basically anything in the club environment that has more demand than supply,
• even seats at the Metropolitan Opera Club in New York!

Member tee sheet redesign

Administrator tee sheet

After:

Details:

The before example was the 2.0 version of the administrator tee sheet when we released the drag and drop functionality. Leveraging the work I did for the member tee sheet, I applied the same styling changes to the administrator side, while also maintaining the key parts that allowed for drag and drop. This required close collaboration with Development to make sure it worked correctly.

Another key part of this UI is the $ icon, which allowed for charging players directly on the tee sheet. Please see Accounting and POS systems for more details.

We also had a rules engine managing who could book and when. I regularly came up with novel ways to structure the rules to make the client requests work because they were so varied. This was a competitive advantage of the system, and once set up it would be very difficult to replicate or change products. I'm proud to have built rules for clubs such as Pinehurst, Congressional Country Club, Valhalla Golf Club, Southern Hills Country Club, Colorado Golf Club, Hamilton Farm Country Club, Baltimore Country Club, any hundreds more!

I could go on in this area at length about the hundreds of updates for which I was product owner because the interface was customized for many different uses and operational processes.

Details:

Clubessential was among the first to release a truly mobile tee sheet and it was certainly MVP and had some early stumbles. The mobile tee sheet was highly anticipated though because of the rising adoption of mobile devices. As a side note: this was released around the same time we finally started to see less than 50% of traffic on some club sites coming from Internet Explorer (yay!) which of course was the usual suspect for any peculiar bugs.

Some strategic accounts were sold primarily on the mobile tee sheet but it wasn't working out. So I took the case to compile feature requests and help manage priority (and also to reassure the accounts that we'd make the members happy). Similar to the updates above, I was able to find a low effort, high impact solution by listening closely to the users and then coordinating with development and executives.

I talked to some key administrators and they were upset. One was even on the verge of tears because it was such a hot topic at the club. Through these interviews I gathered the end user feedback and determined that the layout was a primary source of confusion. The main problems were that the user was given the wrong information and there wasn't a clear distinction between the various states. There were other problems too of course but any good Product or Project Manager knows you have to decide where to focus.

Problem: incorrect order of information

One example of the problem was the user saw the "Book" button before they knew how many spots were available. This seemingly small issue had a major impact. It caused times to be overbooked because the user assumed (and was guided to think) they were the only players in the time. They also didn't notice the party size they had selected. Ultimately this resulted in 8 players showing up when only 4 could play. In the golf world this is nothing short of a disaster, wastes a lot of time and effort, and generally makes the club operations look bad. It had to be addressed.

Solution: reverse the order of the elements

I took this feedback to the developers and you may be able to imagine the initial response as developers tend to be logical and direct people. It's the users fault for not noticing the other players or the party size! Basically there was resistance to invest too much in user error because there was plenty other important priorities, and it would take time and executive prioritization to make any major changes. I didn't give up though and after talking more with the key developer I was able to get a simple update made quickly so I could target the elements differently and avoid the long queue in our backlog.

This simple class update allowed me to use CSS for swapping the order so the 1st thing the user saw were the other player names. That quickly put an end to the mistakes. I made a few other changes too of course but switching the order was the most impactful.