At the end of February, I had a chance to speak with Tom Belden, the "Winging It" business travel columnist for The Philadelphia Inquirer, about an upcoming article in Business Travel Executive. Here's some of what we talked about:
1. How much meeting technology does the average company really need?
I know this is an obvious answer, but planners need just enough technology to meet the requirements of each component of their meeting.
For example, a marketing road show needs to have email marketing and search engine optimization tools in order to drive attendance to their events. A mandatory employee training event, however, only needs an email broadcast capability in order to communicate with the attendees, and sometimes Outlook can serve those needs. The planner needs to start their analysis with the business requirements and processes, then select technologies that streamline these processes, and then use the features of the best technologies to modify the processes in order to take further advantage of their technology investment. Process requirements drive technology selection, but technology capabilities can drive process changes.
2. Hotels are increasingly providing meeting technology for their clients through their own websites or in collaboration with companies like Passkey. Is that all some organizations need?
Hotels typically limit their technology tool offerings to electronic RFP submission and rooming list management. For some meetings, these are sufficient, but most professional meeting planners must deal with more complicated situations requiring their own technology. For example, if your attendees are going to stay at multiple hotels, you will likely need to have a single system recording your event’s housing reservations, instead of flipping between each hotel’s own housing application. Also, planners need to be aware that hotels’ proprietary tools, such as RFP / meeting space search, are designed to drive business to their properties. You won’t always find the best deal for your meeting by sticking with the hotels’ tools.
3. What's been integrated so far? Why were those areas/ partners chosen and how difficult was it to accomplish?
In general, the industry has seen Registration systems integrated with housing systems such as Passkey, travel systems such as corporate booking tools (GetThere, ResX) and GDS’s (Sabre, Worldspan), customer relationship management systems (PeopleSoft, Salesforce.com), employee/human resources databases (Peoplesoft), and credit card processing networks (Paypal, Authorize.net) – in addition to many other integrations with niche applications. The effort involved in these integrations vary greatly between partners and processes. Credit card processing, for example, is a fairly mature technology with established standards and so was the first (and easiest integration) for most registration companies.
We need to make a distinction between technical integration and business process integration. For example, if you want to pass a name from your employee database to the registration system, then you will likely need a technical integration between these two systems. On the other hand, if you want to use email broadcast, blogging, and search engine optimization in order to drive traffic to your event, then you can likely use three different applications without doing any technical integration. You only need to synchronize your use of these technologies as you seek attendees.
Lastly, technical integrations must be maintained. Even though we first integrated Certain Registration with credit card processing in 1998, we spend at least one release every year maintaining that integration - adding new processors, dealing with mergers such as Verisign and Paypal, updating to the latest security standards like Payment Card Industry compliance.
4. What's next in integrating meeting technology? How long will it be before we see any of that -- by the end of 2009?
The next phase of integration will be deep support for programming tools loosely called “Web Services”. Web services provide an interface for other applications and computers to interact with our product. For example, if you want to change your last name, a human user can log in and manually update their last name using an online form. Or the employee database, which already has a record of the name change, can contact the registration application and update the last name for a specific person – automatically and without human intervention. Many suppliers, including Certain, offer “Web services” to a limited extent now, but you will see all vendors expand their support to allow integrating systems to do anything that human users can do.
Another longer-term trend will be the adoption of data exchange standards such as the APEX (Accepted Practices Exchange) and OTA (Open Travel Alliance) XML (Extensible Markup Language). This will allow a single application to interact with a wide market-place of other applications, without having to re-write application code and establish business partnerships with one company at a time, as is the time-consuming norm today.
5. What reasons do meeting planners or travel managers give when they turn you down and say they don't need Certain software to help them?
Inertia is the biggest issue if we are competing against an existing in-house system or process. Although managers recognize the inefficiencies in their existing processes, they sometimes cannot generate the internal motivation to change to a better system.
Cost should never be an issue, since Certain Registration as a Software As A Service (Saas) product offers pay-as-you go plans with little up-front expenses.
Some planners cannot adopt our products due to company policies or internal issues trying to integrated with other in-house systems, such as employee or customer databases. Although technically Certain can and has integrated with many types of systems, the internal resources on the client’s side may not be available and put the entire project on hold.
Recent Posts
- Online Registration - Best Practices Today and Tomorrow (Monday, May 24, 2010)
- Education is now about filtering information, not finding it (Thursday, November 12, 2009)
- How Social Networking Will Affect Privacy and Data Security of Your Events (Thursday, September 10, 2009)
- Using Technology to Reduce Housing Costs at HSMAI Affordable Meetings in Washington D.C. (Wednesday, September 9, 2009)
- Twitter: I don't get it, but I'm going to give it a chance (Wednesday, August 12, 2009)
- When technology saves you time but does not help your work. (Thursday, June 11, 2009)
- Think you'll never attend a meeting in a Virtual World? Look out behind you! (Friday, May 29, 2009)
Showing posts with label Integration. Show all posts
Showing posts with label Integration. Show all posts
Monday, March 30, 2009
Technology Integration in the Meetings Management Sector
Posted by
Rick Borry
at
9:06 AM
Labels:
General Meeting Planning,
In the news,
Integration
Friday, September 05, 2008
Online Travel Systems for Meetings presentation at MTE in Washington D.C.
Wednesday last week, I had the opportunity to present at the Meetings Technology Expo in Washington, D.C. On short notice, Paul Paone asked me to fill in for the Meetings Travel session, so I created a new presentation based on my experience integrating Meetings and Travel systems.
Unlike much of the marketing hype around "Travel Integration" systems, I've found that sometimes inexpensive process modifications can achieve the universal goals of unified meeting-travel reports and proper travel expense assignment for meetings.
Online Travel Systems for Meetings
Below are the slides from my presentation. Click on any image to see a larger version.

Unlike much of the marketing hype around "Travel Integration" systems, I've found that sometimes inexpensive process modifications can achieve the universal goals of unified meeting-travel reports and proper travel expense assignment for meetings.
Online Travel Systems for Meetings
Below are the slides from my presentation. Click on any image to see a larger version.
Posted by
Rick Borry
at
9:46 AM
Labels:
General Meeting Planning,
Integration,
Presentations,
Travel
Friday, November 09, 2007
Online Registration: Life as a small fish in a big ocean
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.
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.
Subscribe to:
Posts (Atom)