Beyond the obvious, your Guest Tile database is your most valuable asset because it is the only list in the world of everyone you know who knows your property. You couldn’t buy that anywhere so it is imperative that you protect and maintain it.
Nonetheless, the value of individual guest’s records can diminish over time if they no longer use your services or respond to your advertising efforts. The downside of retaining them on file has lessened in recent years as direct marketing and its related costs has moved into the digital space, but there is still no advantage to carrying thousands of unproductive names on your rolls.
“Guest clutter” can impede Reservations’ operations making scans and searches more time consuming. It can also have a negative impact on generating batch correspondence and mailing lists for marketing purposes. Finally, there is the question of validity. Approximately 35 million American citizens move every year, roughly 12% of the population. If you are maintaining guests in your system that have produced no activity or have not responded to contact within the past seven or eight years, there is a better than even chance they are no longer reachable.
The Batch (K)ill Guest Tiles utility in SMS|Host is a tool that should be part of your periodic maintenance procedures. The process is very straightforward offering a handful of prompts to help refine the list of unwanted Tiles but some planning on your part can enhance your strategic approach. Here are a couple of ways in which you could mark Tiles in advance that you already know you wish to purge:
- Season Codes are a very old and frequently overlooked resource that can be used to label guests. A maximum of ten single alpha/numeric characters can be authorized for use, one of which can be placed on each Guest Tile. The utility allows you to choose up to five of them in identifying tiles to be considered for deletion.
- A single Source Code can also be used to designate tiles for possible removal. The utility will offer the ability to enter that code if you have one.
In addition to these two prompts, you may choose to exempt from deletion guests whose records have a number greater than zero in the prior Stays field despite the absence of any reservations (e.g. guests converted from a previous system.) A cutoff date must also be provided with which to identify Tiles added on or before that point and, therefore, under consideration for removal.
The final test for deletion will exclude any Guest Tiles with links to other records including active or historical Reservations, Membership or City Ledger accounts, Owner Contracts, Resort Scheduling bookings (including Golf, Dining and/or Spa services) or Waitlist entries.
While not a process to be taken lightly, it is one that should be sensibly deployed following a certain number of years and, thereafter, on an annual basis in an effort to maintain reliable and actionable data.
In the next and final post in this series, we’ll look at a long term solution for very large and active systems.
