Last week Lauren Covington and Stephen Nold at Meeting Tech Online (MTO) published "Registration Tools: What’s New, What’s Next", describing the results of their research into the subject. The topic raised by meeting planners that was of most interest to me was their desire to integrate registration systems with their other back-office systems.
Background: Big ocean, small fish
I'm not sure how big the meetings industry is. Starcite's Web site refers to the $300 billion global events industry, while a January 2007 PhoCusWright study projects "groups and meetings revenue" at $175 billion by 2008. Either way, the market size is really big, but according to the PhoCusWright study travel (air, hotel, car, ground transportation, cruise, travel) accounts for about 54% of the total while non-travel (meeting rooms, catering, audio/visual) accounts for 46%. Starcite's research predicts a $1.5 billion market size by 2010 for meetings technology tools (which I assume includes event RFPs, meeting expense management, meeting planning, online community, and registration applications). If online registration tools accounts for 10% of that total, then $150 million is a nice market niche for a small software company like ours, but this size makes it tough for us to set the technology direction of companies that organize events and spend 1,000 times that amount holding them.
(Comment: Thanks to Michael Boult, Starcite's CEO, for his polite comments correcting my originally reported data and providing additional information.)
Living with multiple systems when you are the smallest of the lot
The result is that we enter systems integration projects from a position of weakness. Companies look at their CRM (Customer Relationship Management), Intranet, and HR employee databases as their primary applications that are critical to business operation. While event management software is crucial to a small number of meeting planners, the rest of the organization spends maybe 15 minutes each year registering for a handful of events. As a software company, we want to build interfaces that others connect to, give them the documentation, and have them go at it. More often, we receive a stack of documentation and are asked how we are going to fit our round peg into their square hole.
Love it or hate it, everybody has it
The first place we started was with Microsoft. By integrating with Internet Explorer (Certain Registration), Outlook (email and calendar appointments), Excel (reports and imports), and Word (labels, badges, and printable documents) - we connect to the tools that 90% of our customers regularly use. The open source movement and competition from Google, IBM, and others have forced Microsoft to expand their products' interoperability slowly but steadily. I expect that Certain Registration and similar products will continue to grow closer to these standard tools in the future.
The key to communication is to speak the same language
Two systems that speak the same language can communicate readily. Two systems using different languages must have an "interpreter" in order to communicate. In software, the cost of building the interpreter can be the difference between winning and losing the business. Because online registration is dependent upon larger systems, we have to learn the languages of the core systems.
When I wrote the second version of Certain Registration (Register123.com) in 2001, I corrected the mistakes of the late 1990s, but I did not have a standard framework to build upon. Now, the software industry has both a standard communication method (Web Services) and language (XML). I've written previously about my efforts to help define a standard language for the events industry through the Convention Industry Council's APEX initiative. I have recently had the chance to review Security Assertion Markup Language (SAML), an established XML communication standard for "Single Sign On", which is the practice of logging in once and being authenticated into multiple applications. (I'll write more on that subject in a future post.)
Eating the elephant one bite at a time...
The reason I spend so much time on XML standards and Web Services is that, while we have integration interfaces now, the future for "minor" applications like registration will be to natively speak the common XML languages of the core applications. Then my clients' developers will be able to select Certain Registration as an off-the-shelf component of the much larger system that they are supporting, and they will be able to quickly exchange data within defined boundaries between our application and their other components.
As I see it now, this is going to be the only way for most organizations to have an "all-in-one" system that includes a professional meeting management component.
Friday, November 09, 2007
Subscribe to:
Posts (Atom)
