Chapter 24 - Best Practices: Managing Historical Data

Why does my ^SMS|Host system run slower than it did a few years ago? This is a question we are asked periodically and, while your hardware, network and operating environment may well be contributing factors, one answer that is frequently involved is size – your system gets bigger. You are continually adding guests and reservations, memberships and city ledgers, groups and golf rounds. Data, data and more data. And, if you’re not following best practices for managing it, you will find   things    gradually           slowing           down.

To be sure, our developers are constantly working to optimize system performance by enhancing our code and streamlining routines and background processes. One great example is the performance of the Housekeeping Console, something that was addressed several version’s back to the appreciation of users in our largest properties. But there are actions you can and should be taking that will have a significant impact on your own property’s experience.

Over the next several posts, we’ll take a look at some of those and how to put together a practical historical data management policy, beginning with your move-to-history schedules. Various databases can benefit from customized periodicity and durations:

• Travel Agencies – These can be the easiest to manage and also the most frequent. By setting your commission postings to consolidate at check-out, you are free to process as often as you like, avoiding confusion from partial stay information while establishing a relationship for reliability with your agency partners. Weekly or bi-weekly processing would not be uncommon.
• Owners – Most owner rental contracts call for monthly distribution, the procedure for which begins with moving the prior month to history. Though some perform this quarterly, the important point is that the process follows a perpetual cycle with an easily established rhythm.
• Memberships and City Ledgers – These, too, tend to follow a progression with monthly billings preceded by an auto-close moving prior transactions to history. It is an easy habit to follow.
• Reservations/Transactions – These are both the most important records to oversee and the ones that most frequently are not. The usual cause for their being undermanaged is the lack of an obvious imperative. There are advantages to maintaining a healthy period of active past reservations but, without an established recurring process, that period can, all too easily, stretch into years.

When reservations are regularly moved to history, the size of these critical databases stabilize within a range that affords consistent performance. A conventional range for seasonal properties maintains a minimum of twelve months’ active plus the full prior occurrence of that season. For example, if winter is an important period (e.g. November through April), then you would keep up to eighteen months active and on May 1^st move the oldest six months to history (i.e. cutoff prior to the previous May 1^st). Then, on November 1^st, again move the oldest six months (i.e. cutoff prior to the previous November 1^st).

Properties generally unaffected by seasonal occupancy might choose to only carry twelve months active by moving the oldest month (one year back) on the first of each month. Again, this helps to preserve a consistent size to their active system minimizing any degradation of performance from the volume of records.

The important part is to create a pattern of activity resulting in more reliable system behavior. Don’t let a lack of oversight ruin your user experience.

Next time, we’ll look at some further ways to improve performance by cleaning up old data.