Cornerstone’s mission in life is automation. Our goal is to enable our customers to reap financial rewards by bringing order to inherently messy activities through the use of our technologies.

The concept is simple: when technology can perform a repeatable activity quickly and accurately, less human effort is required for front-end processing and back-end rework. This being the case, more volume can be processed at the same staffing level, the same volume can be processed with less staff, or some combination of the two whereby staff can be reallocated and used most profitably.

The bottom line: more throughput with fewer costly resources equals improved financial results.

This is a noble and very achievable goal and perfectly suited for the business of travel. Travel is heavily task oriented; very messy; and increasingly low margin for TMCs, OTAs, agency consortia, cruise and tour operators, you name it. And while I can point to many cases where we’ve had great success automating highly complex activities that paid big dividends to our customers, a recent experience reminded me that Robert Burns was right when in 1785 he wrote:

The best laid schemes of Mice and Men
Oft go awry,
And leave us with nothing but grief and pain,
For promised joy!

While every case is unique (every picture tells a story, don’t it? – Rod Stewart/Ron Wood – 1971), and there are good reasons projects don’t always succeed, experience shows us two common reasons automation projects go off the rails, each of which is worth a blog post of its own:

 

  1. Automation requires standardization

    Many conversations with potential customers start with their desire to automate things their people do by hand. This is a reasonable starting point but a dangerous place to end up. Remember that travel is inherently messy and very high touch, so it’s almost certain that what people are doing by hand is inconsistent and inefficient. If this becomes the foundation for automation, all that will happen is that bad results will come faster and more consistently.

    Moving forward with automation first requires taking a step backward. What are your desired outcomes, how close are you to achieving them today, what are the existing bottlenecks and break points, and what is the upside potential if you were to achieve them? You’ll quickly discover that in a manual world few people do the same things the same way (just ask a half dozen agents how they decide when schedule changes need to be revalidated or reissued if you don’t believe me).

    With proper diagnosis a new path can be charted using business rules automation, but remember that business rules by definition are standards: they are objective and not subjective. Make no mistake—your people will do things differently in an automated world, which is why change management is a huge portion of any large-scale automation project. If you can’t accept the fact that automation requires standardizing that which was free-form, your project is likely to fail.

  2. Perfect is the enemy of good

    As noted above, automation is about driving efficiencies—more throughput, reduced handle time, fewer errors. Notice that I didn’t say 100% throughput, zero handle time, and no errors. Any complex process is will have anomalies, one-offs, and exceptions, and travel is a poster child for complexity. In a manual world, these complexities are hidden from view, but when business rules are applied they are exposed to the light of day. Think about travel policy management. Most organizations have one, but when the CEO’s Executive Assistant calls and books first class on a three-hour flight no one blinks. Put that same reservation through an automated business rules system and guess what happens? He or she gets a nasty-gram from the Travel Manager with instructions not to do that again!

    An automation project is the Pareto Principle in action. The biggest bang for the buck will come when 80% of the junk is handled by the technology. And while it is tempting, trying to solve for every potential scenario soon becomes an exercise in futility, the point of diminishing returns will come and go, and the result of the quest for perfection is only frustration and disappointment.

    On the other hand, if we can accept the reality of standardization and define the 80/20 process, build business rules, and measure effectiveness with load testing, the most annoying work will be out of the hands of people so that they can apply their creativity and expertise to the few remaining tasks.

While not every project goes as well as one would hope, there is no failure where there is learning. I hope these thoughts make your next automation project an unqualified success!