Friday, December 22, 2006

"Easy to use" versus Intuitive

When people first inquire about our online registration system, they ask two things: "How much does it cost?" and "Is it easy to use?" At that stage, I have to answer "such and such $$$ per registration" and "yes", because if I took the time to explain why these are the wrong questions to ask, then the prospect would think that I'm waffling. I might as well say, "I'm going to take more money from you than the IRS and in return give you something that is slightly more complicated than your Tax Return in a year when you got married, sold a house, bought another house, closed an S Corporation, and merged 3 kids into a Brady Bunch family (welcome to my tax year). But if only I had time to tell them this...

"Easy to Use" and "Flexible"

What prospects are saying is, "Is this software easy for me to use for my current job tasks, with my specific event planning experience and level of comfort with web-based software." Well, the truth is that some users are so uncomfortable with Internet applications, or even the computer in general, that they will never think an application is "easy". For these people we show what our application can do for them and their customers, and then we offer our "full service" option, where our in-house experts build the client's registration forms, web sites, and reports for them. Presto! - it's easy to use because you don't have to use it at all!

But most of our prospects want to "do it themselves", either to save money or because that is part of their job description, and, well, they like getting a paycheck every month. The challenge for a software designer (like me) is to create software that is both "easy to use" and that can actually do what you need it to. On top of that, it must meet these criteria for a wide audience of paying customers, otherwise the cost of the software would be more than most individuals or companies could bear.

It would be easy to build an application that has a step-by-step wizard that guides a person through the exact process that they follow with their events. This would be "easy to use", that is, until another person tried to use it, and then "whoa! what about discount codes for multiple attendees from the same company - how do I do that?". Then the manager needs to oversee all of her staff and allocate resources appropriately and monitor budgets - but without getting in the way of the employees doing the work. Next the executives take the business in a new direction or merge with another company, and suddenly the processes that have worked for six years need to be changed to meet this new reality.

Okay, so what the prospect really wants is "easy to use" and "flexible". So we design a wizard that asks questions about what you need for this event - Fees or Free? Breakout Sessions? CEUs? Guests? Hotel Rooms? Air Travel? - but this can go on and on until the user becomes annoyed having to constantly tell the system what they do and don't do with each event. So we give you templates, so you don't have to answer these questions with each repeat event; you only answer them with the new events. This struggle between easy and flexible goes on and on, and is in the forefront of our software design.

"Easy to Use" and "Intuitive"

"Intuitive" is a better goal to keep in mind when designing software. Can the user approach the application (without training or assumption of skill levels) and intuitively know how to approach the application, and where to start in order to get their immediate task accomplished? People don't actually expect software to do their job for them, they just want it to help them do their job that much faster. Don't make me answer questions about what I want to do - I know what I want to do, just help me do it.

Concepts in Practice

The concept of "Intuitive" has been in the front of my mind lately because we are currently re-designing the Register123 user interface. We are working with Bruce Browne, a software design expert who previously worked with Apple and Intuit on the Quicken application.

First, I have a week off to spend the Holidays with my family in the Colorado snow, but starting next year I'm going to discuss the design process that we've used in order to improve our software, and hopefully achieve the elusive goal of "easy to use".

Merry Christmas and Happy Holidays to you and your family.

Monday, December 18, 2006

Early adoptors aim to implement APEX standards

This week marks my one-year anniversary of joining the APEX Technology Advisory Committee (TAC). During this period, my company donated close to $50,000 in time and travel expenses towards the meeting industry's efforts to create XML standards for electronic data exchange. This investment was made on faith in the APEX goals, but I'll need to show a return on this investment by the time I reach my second-year anniversary. Here's how I plan to do that...

APEX Strategy

As I've described in many posts this year, APEX focussed its efforts in 2006 on creating XML standards through the Open Travel Alliance. We produced 3 schemas:

  • Single Facility Event RFP
  • Housing Rooming List
  • Event Specification Guide

Now that we have completed the XML framework, we decided to focus efforts in 2007 on implementation of the APEX XML standards in real-world applications. Our intention is to show the industry how they can use these standards to make their lives easier. Once we have proven this, we expect to get a flood of new "converts" to the APEX religion.

If development goes as planned, the MPI World Education Congress in Montreal on July 28-31, 2007 will be our big "coming-out" party. EJ Siwek (the APEX TAC chair) plans to host at least five 90-minute sessions in order to educate meeting professionals in attendance about the implementation of APEX standards within Certain Registration and other meeting planning software applications.

Implementation Plans

The current implementation phase is when the hard-core developers come out and do their stuff. While companies are free to implement APEX XML standards any way they please, I expect most organizations will build a "translator" interface between their proprietary database and the APEX standards. The process will look something like this:

The beauty of XML is that each company will only have to build the translator between their database application and the APEX/OTA standard. Data exchnage will use existing standards (e.g., SOAP / HTTP) that all web-based applications can readily accommodate, and standard processes (e.g., XSLT) exist for converting XML into document-based reports.

How to get involved

If you want to get involved in the implementation phase, then you (or someone who can read XML) need to do the following:

  • Join the APEX TAC at our web site ( Here you can download our calendar of meetings and add yourself to the notification email list.
  • Download the current XML standards (OTA 2006B) from the OpenTravel Alliance. This download contains hundreds of files, of which only a few apply to the APEX initiative for group travel / meeting planners:
    • OTA_MessageUsersGuide2006BV1.0.pdf - The "Message Users Guide" contains a high-level description of each OTA Message with sample use cases and XML instance documents.
    • \_OTA_CodeTable\OTA_CodeTable20061211.xls - The code table contains the text descriptors for OTA standard codes used in the XML messages. For example, the "Event Type" code 11 means "Sales Meeting"
    • \_OTA2006B_XML\OTA_HotelEventRQ.xsd - The XML schema for the Event Specification Guide (RQ is used for "Request" and RS is "Response")
    • \_OTA2006B_XML\OTA_HotelRFP_MeetingRQ.xsd - The XML schema for the Event RFP
    • \_OTA2006B_XML\OTA_HotelRoomListRQ.xsd - The XML schema for the Housing Rooming List
  • Download the latest version of the APEX standard reports in document format. These are available in the APEX Toolkit, or online at the APEX web site.
  • Get a copy of the APEX workbook from the TAC web site. The workbook is produced by APEX's "doc tool", and contains a translation from each field in the Word-document versions of the APEX reports and their corresponding elements in the APEX/OTA XML schemas.

In addition, I recommend getting a good XML editor - I used the Altova XMLSpy 2006 Professional Edition to help write the standards.

Monday, December 11, 2006

Behind the Scenes: Setting Up and Managing a Blog

Well, I've been practicing this Blog thing for a few months now and I've decided to roll it out to the public. It was easier than I thought it would be to set up a Blog, but harder than I thought to manage an email subscription list.

Setting up a Blog

This part was easy. I choose Blogger (a Google subsidiary), because I had heard of it before and it only took me five minutes to get started. I wasn't frustrated enough to try anything else, but I've heard that Yahoo! has a pretty good blog engine now. I spent a half-day customizing the template so that I could set up the side bar you see on this page, but besides that the only time I spend on this Blog is the time it takes me to write the posts.

Managing a Subscriber Base

I thought that I could use Blogger to manage a subscriber database, but that turned out not to work. I want people to be able to subscribe or unsubscribe to my Blog so that I can notify them via email each time I make a new post.

After a little research, I found a free web-based subscription database management tool called Mach5 Subscriber. It's limited to 5,000 contacts, but when I have more readers than that then I'll be willing to upgrade to the paid version. In a few minutes I set up an account, selected the data that I want to collect from my audience, and Subscriber instantly created both a subscription signup page and a subscription management page. I then added these hyperlinks to my Blog so that readers can subscribe and unsubscribe from my email list.

Sending Notification Emails

The next step was to find a tool to let me send bulk email to my subscriber list. Mach5 has another product for this purpose, Mach5 Mailer, which is also free up to 50 emails at a time. This is a Windows-based application that integrates with Subscriber in order to allow users to send personal, customized emails to your subscription list. It sends both HTML and text versions, and can contain hyperlinks to your Mach5 Subscriber pages for your audience to manage their subscription.

The last hurdle was to find an email server that I could use to send the notification emails. Outgoing email requires a SMTP (Simple Mail Transfer Protocol) server. Fortunately, Greg Paik, the Director of Network Engineering at Certain, allowed me to use our Exchange server for the small scale of my current subscription database. Our SMTP Server requires me to connect to our VPN first in order to prevent unauthorized users from relaying spam through our network, but this isn't a big deal from my laptop, even when I'm on the road. When I outgrow the scale of Mach5's free tools, then I'll need to find another option for mail delivery. (Mach5 is working on a product called Mailer Express that will hopefully do this.)

Putting It All Together

Now I have the Blog, subscription database, bulk mail merge application, and outgoing email server. Each time I post to the blog, I'll send an email to the current subscriber list with the first paragraph and a hyperlink to the full posting. If you want to add or remove yourself from the subscription list, it's as easy as clicking on the hyperlinks in the email or on the left column of this page. And I hope that readers will send me topics that they would like me to discuss, and forward the subscription emails to their friends and colleagues.

Let the experiment begin!

Friday, November 17, 2006

On-Site Registration at the 79th Annual National FFA Convention

Indianapolis SkylineBob Osborn, Brett Weigl, and I were on-site with the FFA at their National Convention from October 23-26 in Indianapolis. With over 50,000 attendees, this was the largest convention to date that used Register123 for on-site registration.

FFA closed pre-registration on October 11, two weeks prior to the event. After that, attendees had to register on-site. For an event of this size, these two weeks allowed the FFA staff to complete on-site preparations without a constant flux of registrations and cancellations.

We flew into Indianapolis on Monday so that we could set up the Internet connections and confirm the system configuration. For the on-site event, we created special registration forms that focussed on rapid data entry rather than custom branding.

On-site registrants started at the information desk. This area helped attendees determine if they needed to enter the registration line, if they needed to walk to the "Issues Desk", or if they simply needed to have name badges printed for exhibitors.

Attendees who entered the Registration queue saw the event agenda twice. Sessions that had sold out were posted clearly so that people wouldn't try to buy tickets for unavailable sessions at the counter.

Notice that only 1 row of the 5 set up in the queue was full. Lines and wait times were reduced by about 75% compared to 2005, mainly because so many more attendees participated in the new online registration process. People who did want to register on-site completed a paper form while in the registration line, so that they would be ready to purchase tickets when their turn came up.

FFA set up 6 registration stations with 2 workers per station. Around the corner to the left is the "Issues Desk", which served people who lost tickets or needed to change their pre-registration order. Because of the higher proportion of pre-registrations this year, the "Issues Desk" line was longer than in past years.

Behind the counter, registration desk workers used the new "Admin-side Forms" in Register123 to quickly process on-site registrations, collect payment, and print out confirmations and receipts. FFA receives a large number of P.O., check, and cash payments on-site, although the percentage of credit card payments increased this year.

After the front line workers entered the registration data, the system sent a "Pick Plan" to the back office workers. These employees selected the purchased tickets, bundled them with the registration materials, and met the attendee at the end of the registration desk. All transactions were monitored by FFA's registration manager (Sheridan Gilchrist) from a second-row PC station.

Meanwhile, I sat in the back-office at another monitoring station. Here I looked for issues and created special reports for FFA. This year was something of a learning experience for us, and these reports will become part of the standard features in Register123 for next years' events.

Overall, the on-site registration process went very smoothly. We lost Internet access on the first day for a few minutes, which was quickly addressed by the convention services. Now that Internet access is approaching the reliability of electricity in modern convention centers, the major problem with using an online registration system on-site is being eliminated.

Lessons Learned
In 2007, we plan to reduce the number of manned registration stations from 6 to 4, and to add 2 "Self-serve registration kiosks". These kiosks will allow people to register themselves on-site via Register123, as long as they are paying by credit card. One FFA worker will "float" between the two self-serve kiosks, in order to help attendees who have trouble. This process should work much like the self-service check-in stations at airports.

Also, we will likely add a second "Issues Counter", in order to handle the increased number of pre-registrants who need to make changes to their registrations on-site.

Lastly, we will modify the on-site name badge printing form in order to reduce the number of steps required to print a name badge. Thanks to Register123's flexibility, these process changes can be configured without any software development.

Wednesday, October 25, 2006

On the front lines at the 79th Annual National FFA Convention in Indianapolis

Nearly two years ago, Certain won the contract to handle online registration for all events sponsored by the National FFA Organization.


The FFA (formerly called the "Future Farmers of America") is a national association of state FFA chapters. They hired Jeff Rasco and Rod Marymor of Tech3 Partners to mangage their selection of an Online Convention Registration (OCR) application. Tech3 worked with FFA to determine their key needs and to deliver a detailed RFP to all major online event registration vendors. Certain was one of four finalists selected to present to the FFA operations committee at their headquarters, and in March 2005 we signed a multi-year contract.

Time to Deliver

Now, 18 months later, the 79th National FFA Convention begins today at the RCA Dome and convention center in Indianapolis. After a pilot test at last year's convention in Louisville, the implementation team from Certain (Bob Osborn, Sr. Account Manager, Brett Weigl, Director of Client Services, and I) was ready to handle FFA's somewhat unique online registration requirements. These include:

  • The National FFA Convention will have around 50,000 attendees, separated into about 50 groups such such as exhibitors, members, alumni, advisors, parents, staff, press, speakers, judges, etc. FFA used Register123's unlimited registration categories to manage these groups.
  • With 50,000 attendees, the FFA had to schedule three Opening Sessions of ~15,000 - 18,000 each in the RCA Dome. They wanted to limit the total number of tickets selected for any of the three Opening Sessions to be equal to or less than the total number of registrations purchased. (Apparently, in past years some advisors took advantage of an older registration system by splitting their groups into multiple Opening Sessions and getting more "free" opening session tickets than the number of registrations they purchased.) FFA used Register123 Packages and Form Logic in order to enforce this complex business requirement.
  • FFA has an existing Web Site with state chapter login, which is integrated with their PeopleSoft CRM database. They used Register123 Form Integration features to seamlessly pass state chapter information from their web site intranet to the registration form when each registrant clicked on the "Register" hyperlink.

Ticket Management

  • State chapter advisors register multiple student attendees at once, and FFA only collects the contact information for the advisors. FFA used Register123's unlimited Program Module in order to enter more than 175 sessions, tours, concerts, parking passes, etc., where advisors purchased 1-100 tickets at a time for each item.
  • FFA delivers paper tickets and purchased items to all pre-registered attendees. They used Register123 Personal Documents to create a custom "Pick Plan", which their warehouse technicians used to prepare indivudal packets and ship via UPS.
  • FFA also used Register123 Web Integration Links to integrate with the UPS Worldship application, so that employees or attendees could use their Registration Code to track their package shipment on the UPS web site with a single click.


  • The National FFA Convention must cover its expenses through registration fees and additional fees for tours and concerts. FFA processed over a million dollars via Register123's Financial Module using integrated credit card processing and check/P.O. payments.
  • FFA uses Peoplesoft Financials and CRM application as their association management solution. Their IT team used Register123's Budget Module to store the PeopleSoft General Ledger Account Numbers with each fee, and Register123 Custom Reports to create batch files with payment and fee information. The reports were customized with the column headers and tab-delimited text format required by FFA's automatic nightly import into Peoplesoft.


  • The FFA worked with the Indianapolis Convention & Visitors Association (ICVA) to contract rooms with nearly every hotel in Indianapolis (162 hotels with 12,000 peak room nights and over 30,000 total room nights). The ICVA used Passkey to manage the city-wide housing reservations for FFA. Register123 integrates with Passkey to provide a seamless registration system for attendees.
  • In order to meet their hotel commitments, the FFA offered discounted registration ($30 vs. $40 per person) for attendees who book inside their room block. Because students often stay four or five per room, the FFA wanted to allow only up to 5 discounted registrations per room reservation processed within the block. FFA used Register123's "Packages" feature of the Program Module and "Form Logic" feature in order to enforce these business requirements on their attendees.

On-Site Registration

  • About 10,000 attendees and advisors register on-site, and many pay with cash or pre-printed checks drawn on purchase orders. FFA used Register123's on-site registration features to create simple "Admin-side forms" that registration desk temp workers were able to learn and use after less than 10 minutes of training.
  • FFA used Register123's "split payments" and "cash payments" features in order to process multiple payments against a single order, to accept cash on-site, and to calculate change. Register123 payments reports tracked cash receipts per registration desk worker (with an audit trail based on user name and date-time posted) in order to maintain cash security on-site. (The six foot - six inch off-duty police officer helped this situation, I think.)

I'll post more information (and pictures) tomorrow showing all of this in action from behind the on-site registration desk.

Friday, October 20, 2006

UI and UE Design for web-based applications

On Monday, Certain started a design process to overhaul our User Interface (UI) and our User Experience (UE).

Why design matters

Our online registration application is used by over 50 people for their livelihood. Hundreds of our most active users spend a majority of their workday with it. And thousands of event attendees rely on it for about ten minutes a day. The attendees just expect it to work without explanation, and to let them get on with their day. The users need it to boost their efficiency so that they can justify increased pay, decreased hours, and reduced frustration. Our employees need Certain Registration to bring in revenue so that the company can grow with us.

The current application uses a design created in 2001. So the design that we produce over the next 3 months will affect the lives of millions of people for the rest of this decade and beyond. Good design is not easy, and it's definitely not automatic.

Who can do design

You don't have to wear stylish black clothes and square-rimmed glasses to do good software design. You need to know how the users of the application work on a daily basis, what tasks they need to accomplish, and what the application currently lacks. This knowledge is gained through observation, and observation changes with perspective. So I brought together creative minds from all departments: Kathy Isola (Sales), Ryan Manville and Kevin Linder (Development), Jason Whittenberg, Alan Rhody, and Katie Schuler Herstein (Product Design), Cole Blevins and Bob Osborn (Client Services), Paul Bosky (Training), Dana Chrisler (Marketing), Doug Goldman (Founder), and Bruce Browne (External Design Expert).

How to do design

We used Bruce Browne’s design methodology from his Quicken days with Intuit:

  1. Define goals and objectives
  2. Research and Review: Evaluate existing interface. Identify key problem areas. Map current application organization. Review groupings of tasks/features.
  3. Brainstorm new designs: Break into groups of 1-2 people to produce design alternatives, with each group focused on one Use Case.
  4. Review: Present designs to larger group for evaluation using objective criteria, and select design metaphors for further refinement and evaluation


Over the next several weeks, we will continue to refine our design and post new mockups and wireframes in an internal Wiki for review and comment. Then, we will open the best designs to our community of expert Users, for their comment and further refinement. I'll continue to update you on our progress as we go.

Friday, October 13, 2006

EyeForTravel Travel Distribution Summit USA 2006

Last week I spent a day in Chicago at the EyeForTravel travel distribution summit. I attended a joint session sponsored by several of the travel industry associations who are working together to improve electronic trading between partners in the transient and group travel markets.
  • Open Travel Alliance (OTA) - development of a commonly accepted communications process using XML standards
  • Hotel Electronic Distribution Network Association (HEDNA) - focussed on identifying distribution opportunities and providing solutions for the lodging industry
  • Hotel Technology Next Generation (HTNG) - an industry organization founded to facilitate the development of next-generation, customer-centric technologies to better meet the needs of the global hotel community
  • Accepted Practices Exchange (APEX) - an initiative of the Convention Industry Council uniting the meeting, convention, and exhibition industry in the development and implementation of voluntary standards

Yep - it looks like another bowl of alphabet soup. After a few hours of Powerpoint nirvana, I think I figured out how these groups are going to help me.

HEDNA works on technical issues that currently complicate electronic distribution of hotel products. For example, the hotel industry does not currently have a globally unique "property id" for each location, the way the airline industry has unique 3-letter codes for every airport. This complicates electronic distribution of hotel information, since the various databases that try to aggregate hotel data cannot be sure which facility is referenced in a transaction.

OTA is producing XML schemas that will be used to communicate between various trading partners in the travel industry. APEX is working with OTA to develop the XML standards that relate to *group travel* (as opposed to transient, single-person travel).

HTNG takes the work of HEDNA and OTA and works to implement these standards into practical applications used by the hotel industry.

So in the end, HEDNA will produce a list of unique hotel facility codes, OTA and APEX will produce an open XML standard that defines how two trading partners will send the unique property code between each other, and HTNG will certify applications that use a proven sub-set of the OTA standards in order to transact business in the real world.

See that? It only took you 10 minutes to figure out the alphabet soup and you didn't have to sit through any Powerpoints.

Friday, October 06, 2006

How do web-based event management solutions protect customer data?

Event Solutions magazine requested content for an article about how event management solutions like Register123 help protect customer data, compared to using manual systems like Excel spreadsheets to track financial information, credit cards, personal data, etc. While I cannot tout specific Register123 features in a contributed article, I can do that here.

The short answer to this question is that, compared to manual systems like Excel, Register123:

  • Collects data safely
  • Transfers data safely
  • Stores data safely
  • Monitors potential vulnerabilities better
Data Collection
Online registration systems collect private and financial data more securely than do paper, email, or phone processes. With Register123, registrants can submit credit card payments without any human (other than themselves) seeing the cardholder information. With traditional systems, someone within the event management office must receive and reenter the credit card information into their transaction system.

Data Transfer
Another threat to private information is during data transfer between parties. R123 transfers data using 128-bit encryption standards via https, so that only the sender and recipient can read the information. With email, flash drives, and paper files, data can be read by anyone who happens to see it in transit between the two parties.

Data Storage
Register123 stores data more securely than do typical computer systems. Credit card numbers are encrypted prior to storage in the database and are deleted physically 90 days after the event ends. Card security codes (CVV numbers) are never stored, and address verification is used to validate cardholder authenticity. Our database is located behind a dual-zone firewall, and undergoes continuous intrusion detection, anti-virus protection, physical security, and anti-hacker monitoring. This storage environment is much more save then the typical event management practice of storing data in unencrypted Excel spreadsheets on desktops that don’t use file-level password protection.

The greatest threat to personal and financial data is through human error and theft. With Register123, all data is stored securely in a central location, which is less vulnerable to data theft compared to files stored on easily-stolen laptops or desktop PCs with screens that are visible to any passer-by.

Certain Software and other organizations that adhere to the Payment Card Industry (PCI) standards must perform background and credit checks on all employees, and we must "silo" data access on an "as needed" basis. This level of human security is closer to that found in banks and other financial institutions that deal with PCI standards, and the result is higher data security when compared to the typically open environment of many event management organizations.

In addition to monitoring human vulnerabilities, Certain subscribes to anti-virus and anti-hacking programs that daily update known technical vulnerabilities. Our server farm also has an intrusion detection routine that looks for suspicious behavior on our network and alerts our team if something is amiss.

Friday, September 29, 2006

Scalability - How to keep data flowing as registration volume increases

I spent two drizzly days in Seattle last week visiting some of our best clients, including Weyerhaeuser and Safeco. With our phenomenal growth over the past two years (we've processed over 2.7 million registrations in 2006 - already twice as much as last year), we continually have to upgrade our servers and network equipment in order to handle the increased load. So what can we do to make sure that registration forms respond quickly when 10,000 people try to log onto the system at the same time?

The first thing to realize is that event registration is a very demanding web-based process. A single page of an online registration form will require 10-100 times as much computer processing power as a single page of a content-driven web site such as Yahoo! This is because registration systems involve a great deal of data storage and retrieval, while news sites simply deliver static web pages to viewers.

So to keep the registrations flowing, we have to eliminate bottle-necks at every step of the process:
  1. Registrant requests a page from their browser
  2. Certain's servers receive the request and pass it to one of several web servers
  3. The web servers handle the request and retrieve and store data into the database
  4. The database server processes individual queries to read or write information
  5. Backup systems make copies of the data to disc and magnetic tape
  6. Security systems monitor the process to prevent unauthorized intrusion

All of this processing must occur within about a half-second, or the registrant will "feel" like the system is sluggish.

So to go from a million registrations per year to two million, to four million, to ten million, we continue to make large investments in our network operations.


The first requirement is to make sure that data can get in and out of our servers fast enough to handle all incoming page requests. Internet "bandwidth" is a measurement of how much data can be transmitted in a given period of time. Internet Service Providers (ISP) measure bandwidth by both average usage and peak usage. For example, in September 2006 we increased our bandwidth from "1/10" to "2/100". This means that we pay for a monthly average usage of 2 Mbps (Megabits per second), but we are allowed to use up to 100 Mbps during peak periods.

For comparision, an average web page has about 100 Kb (kilobytes) of text and images. That means that the web server had to deliver 100,000 bytes, or about 800,000 bits since there are 8 bits in a byte. (Note that these calculations aren't exact, due to various small descrepancies between measuring systems of disc, computer, and network engineers.) With a million bits in a megabit, you would need 0.8 Mbps to receive the page in a second. High definition digital cable requires about 20 Mbps to deliver HD movies to your monitor.

Our current daily average bandwidth usage is just over 1 mbps, and our peak usage is around 15 mbps, so we have plenty of room for future growth and spike loads.

Software Foundation

Another way to improve performance is to upgrade the underlying software that the web and database servers use to deliver the page requests. We currently are upgrading our database servers from 32-bit Microsoft SQL Server 2000 to 64-bit Microsoft SQL Server 2005. This allows the database to process requests for information much faster. In addition, SQL Server 2005 allows for simple configuration of clusters of multiple servers. Instead of using one database server for processing and another as a backup in case of failure, we can use the processing power of multiple servers, which improve performance during normal operation and provide for redundancy during periods of failure.

Data Storage

With a data intensive application such as online registration, the overall performance can be limited by how fast the servers can read and write the data to disk. We are implementing high-speed Storage Area Networks (SAN), which improve speeds by orders of magnitude for more rapid read/write actions to discs and for database transaction log backups.

Application Architecture

Once the network, hardware, and software foundations are ready for high performance, it's up to the application to deliver.

  • First, we are modifying Register123 to “cache” information, such as event and form configuration, that does not frequently change. Data stored in the cache is located in the ultra-fast memory of web servers, so when a page request comes in, the information can be delivered immediately instead of requiring a round-trip request to the (relatively) slower database servers. The specifics of caching are complex, but basically if the information has changed, then the web servers will automtically update the information in the cache from that in the database (this is called "refreshing the cache"). Caching will reduce database utilization by up to 35% per page without any sacrifice to the Users' experience.
  • Second, we are going to implement a queue system for incoming requests. During the vast majority of time, registrations will be handled immediately when our servers receive the request. But in rare periods of exceptionally high demand (when database utilization exceeds 75%), incoming requests will be placed in a queue and handled on a “first-come, first-served” basis. While in the queue, registrants will see a “System Processing” message, much like the ones on online travel sites that so many Internet users have seen before. Their total wait time will be a few seconds (depending on system load), which is vastly superior to not being able to access the system at all.

Performance improvement is a never-ending battle with increasing registration volume. It is one that Certain Software is committed to win.

Monday, September 25, 2006

The future of meetings technology companies

Last week, Don Lipper of WRITE THE FIRST TIME asked me some questions for an article he is writing for Perspective Magazine about the future of meeting planning technology.

Q. Technology will only go so far - what services require a human touch? Will that always be the case?

I anticipate that the following services will continue to require a human touch:

  • Creating new business relationships that involve the exchange of large sums of money.

This will always require a human touch; however, the definition of "large sums of money" will continue to increase. For example, in 1995, most people would not buy a book for $50 online because of fears about the security and integrity of the transaction. By 2000, many people were comfortable buying a $500 airline ticket online, without speaking to an agent. In 2005, some people are willing to buy a $25,000 car online at eBay Motors, without meeting the seller. Today, most people would not buy a $250,000 house without meeting someone (the owner or agent) in person, but in the future that may change. But it will be a long time before a business will engage in a $25 million transaction without at least once meeting the owner or agent, looking them in the eye, and shaking their hand.

  • "Greeting" and "Host" positions

You may book a plane ticket online, drive yourself to the airport, ride an automatic train to the terminal, and check-in online; but if there isn’t a human standing behind the counter when you arrive, you’ll think the airline has folded overnight.

In the future, however, the positions where human greeters are expected will diminish. Future chains of budget hotels could run automatically, with self check-in / check-out and automated cleaning. But humans will always be needed to handle the situations that the software programmers did not anticipate.

  • Having fun

"Experience-based" meetings work for networking because they are fun, and you remember people who you have fun with. Even the most die-hard video gamer who lives alone, works at home, has pizza delivered three times a day, and plays MegaQuest 2000 all night will likely have a network of similar recluses scattered around the world who play the team version of the game online and text chat for hours each day.

  • Doing something new

Technology is great at doing the same thing over and over, and advanced technology can anticipate changes in its environment and adapt automatically. But humans are needed to do something truly new and creative. However, after the "new" process, event, or product has been done a few times by humans, watch out because the technology will take over and humans will have to find something else that is "new".

  • Being inspirational

Think of the best motivational speakers you’ve heard at an event. A machine could run a laser sound and light show and chant slogans and display images of what you should do and what you should not do. But people want to see a human standing up there – someone who makes them think, "this person is just like me – and look what they did". That experience inspires behavior change and recharges the soul. Technology will never be able to do this because you can’t relate to technology – instead you would think, "machines have it easy because they don’t face the same obstacles that I do".

That said, technology can help people who are truly inspirational to spread their story faster and to a wider audience.

Q. Where do you see the most consolidation in the future?

  • Group Travel from the attendee perspective: Registration, Housing, Travel.

It will be easier for attendees to confirm that they are going to a meeting, and then have their air, ground transportation, hotel, activities, meeting agenda, maps and FAQs completed and confirmed in a single itinerary

  • Group Travel from the meeting planners perspective

The hotel, the air travel agency, the event planner, and the suppliers will each have their own system that best meets the needs of their business. But their systems will be able to "talk" to each other so that when the travel agent changes a flight from Monday to Tuesday, the Meeting Planner’s system gets the change, and automatically sends it to the Hotel to update the room reservation.

  • Meeting management and attendee management

Information about the event – from the meeting request to the hotel RFPs to the Event Specification Guide – will integrate seamlessly with attendee data management systems. So when a registrant cancels their Wednesday night dinner in the online registration system, the BEO (Banquet Event Order) for the hotel will get the change, and the budget and expense management systems will be updated automatically.

  • Small technology providers will merge to form larger companies

As products and business models mature, the many innovative small companies that were created around event technology in the past 10 years will continue to come together to form a smaller number of larger, more efficient technology providers.

Q. What is driving that consolidation, is it acquisition of territory or technology?

The consolidation of companies is being driven by the maturation of the technology providers’ business models, the desire of early-stage investors to realize a return on their investment, and the market demand for more comprehensive (and thus more complex) applications that will address all of their concerns. Small companies have overlapping overhead expenses that can be eliminated through mergers. Combining customer bases provide increased revenue for greater investment in technology enhancements. And complex software, by its nature, is expensive to develop the first time but very inexpensive to repeat for multiple customers.

Today, it is so easy for technology companies to operate nationally and internationally that local territory strength is not as big of a driving factor for these mergers as are the financial and technology reasons.

Q. When the dust settles five to ten years from now, who will be the winners? Will a single standard platform emerge or will there always be a place for focused standalone best of breed applications alongside with total solution suites?

The big winners will be the meeting planners – unless they allow one company to dominate the marketplace. The meetings technology industry will be better-served by a few major providers then it is now by scores of small players. But competition is healthy for the market as it keeps costs reasonable for planners and drives technology companies to achieve their best.

My hope (and expectation) is that the single platform that emerges will be the set of data communication standards being developed by APEX (through the Convention Industry Council) and OTA (the Open Travel Alliance). Technology providers will build systems that fit their customer base niche, but adhere to the open standards when they communicate with other systems. I expect that each segment of the group travel market will have a few major players who offer a single platform, but that the systems will be different for the different segments. For example, meeting planners will have 2-3 vendors providing integrated meeting and attendee management software – this makes more sense for them then having one meeting management system and another attendee management system. But hotels will have completely different systems (maybe provided by a few different providers), travel agencies will have yet another suite of tools, etc. It makes little sense for a travel agency or meeting planner to have 2 tools in their organization, but it makes less sense for travel agencies and meeting planners to be using the same tool that does everything for everyone. A more practical model is for major technology providers to produce a single best-of-breed suite for each market, and then these suites communicate via open XML standards such as those defined by APEX and OTA. This is why I joined the APEX Technology Advisory Committee and spend hours each month contributing to the development of these standards.

Looking ahead even further, once the major platforms establish a large customer base and adopt the open standards, new opportunities will open for niche applications. These niche applications could use the open standards to extend the core functionality of the major platform in order to provide a specific feature needed only by one relatively small market niche. The major platforms will not be able to invest in development of highly-specific features for small market niches, but a small business could fulfill that need while integrating within the major platform so that the overall experience of the end user is seamless – from the meeting planners perspective they think they are using one application. For example, a provider of photo-ID name badges for events could use the open web services to add their functionality to the 2 or 3 major registration system platforms. Such a function fills too small of a niche for a mainstream registration product to address in its core platform, but it would fit in nicely as an add-on product so that the meeting planners who need it don't have to use a separate application to fill this need.

Friday, September 15, 2006

APEX and the future of meeting data transfer

Yesterday, I spoke at the Society of Government Meeting Professionals (SGMP) North Texas chapter luncheon at the DFW airport Hyatt Regency. The Hyatt just finished a renovation of there meeting space, and if you need a central location for a nation-wide meeting then this is a good place. DFW is within a three-hour flight of most of the U.S., and the hotel manager seems to be willing to make deals in order to fill this new space.

I created a new PowerPoint for this presentation, and I think it worked well for describing to a non-technical audience how APEX is going to help make the lives of average meeting planners better. I'll attach the slides after this post.

Friday, September 01, 2006

The future of data exchange in the meetings and travel industries: Open Travel Alliance

The Open Travel Alliance (OTA) is an association of companies involved in the global travel marketplace. Most major airlines, hotels, car rental and ground transportation companies, cruise lines, and activity operators participate to some extent in the OTA.

The primary goal of OTA is to "transform the travel industry into a single global marketplace of products and services... through development of a commonly accepted communications process using XML". This means that the OTA will develop a common data language, which participants in the travel industry will agree to use in their data communication with one another.

The OTA publishes its XML standards twice a year (June and December), and anyone can download the current standards at after completing a free registration.

Currently, the Convention Industry Council (CIC) represents the meetings (group travel) industry to the OTA through its Accepted Practices Exchange (APEX) initiative. Members of the APEX Technology Advisory Committee (TAC), like EJ Siwek and myself, work with the OTA's Hotel Working Group (HWG) in order to produce XML standards that meeting professionals can use to communicate with their Hotel trading partners.

APEX has made progress in this work with OTA.
  • The Hotel RFP standard was included in OTA's 2005B release (December 2005)
  • The Rooming List standard was included in OTA's 2006A release (June 2006)
  • The Event Specification Guids (ESG) will be included in OTA's 2006B release (December 2006)

Extensible Markup Language (XML) provides a text-based means to give structure to information. For example, if I tried to give my contact information to a computer system as I would to a human, e.g.

Rick Borry

It is doubtful if all systems would correctly interpret my information. If I apply XML to the information, however, then any system that understands the XML standard could correctly interpret my information, e.g.

In this manner, my contact information has structure, and the computer systems that pass the data back and forth can clearly understand that "Rick" is my first name and "Borry" is my last name.

Friday, August 25, 2006

The future of data exchange in the meetings and travel industries

Trying to get two systems to work together is a pain, so companies pay big money and adjust their business practices as they try to do everything in one system. But in reality, one system cannot handle all of the data management processes a business has - and if it did then it would be obselete the next day because these processes change constantly. So the future of software will be much like today - humans will need to use multiple systems and IT people need to somehow get them to work together.

The current paradigm in the software world is that some day "Web Services" will magically tie all of your systems together. Web Services is a clever marketing term from somewhere like IBM or Microsoft, and it basically means that Web-based software applications have an interface that other computer applications can talk to. If you are reading this post, then you are familiar with human-to-server interfaces. The web browser is an interface for humans to receive and respond to information stored on web servers. In the same way, Web Services are an interface for computer-to-computer interaction. This allows an online event registration system, like Certain Software's Register123, to submit credit card information to an Internet payment gateway, like Verisign, and receive a response accepting or denying the desired transaction. The Register123 computer communicates with the Verisign computer through a rudimentary web service, and then displays the result to the human requestor through a web browser.

In order for communication to occur, the two parties must speak the same language. Every computer application that was built independently will speak a different "data language", and if two systems are to talk then one side or the other has to build a translator so that communication is in the same language. Since the world has thousands of systems, it's no more practical to build thousands of translators than it is for a single human to learn every language. So software developers across various companies, industries, and countries get together and define standards - a common language that all agree upon. With standards, each company only needs to build one translator that takes data from their application's format into the industry standard, and then (in theory) they can interact with every other system that speaks the language of that common standard. Humans have tried to do this with the universal language "Esperanto", but it appears that computers are going to achieve a common communication standard before humans do.

For the next few weeks, I'm going to discuss an alphabet soup of topics that will soon bring a common data language to the members of the meetings and group travel industry.
  • XML
  • OTA
  • APEX
  • ESG

Monday, August 21, 2006

Modern Miracles

My Father had his kidney removed last week due to a cancerous tumor. Thank you to everyone who expressed their good wishes to me. He is back home from the hospital and should experience a full recovery.

Two weeks ago he had bronchitis and went to the doctor for a routine chest X-ray. The results showed some dark spots on his lungs, which my Dad said always appear on his chest X-rays due to some childhood scarring. Nevertheless, the doctor wanted to be careful and ordered an MRI. Fortunately, the MRI technician scanned a little bit lower than normal, and while the chest was clear, they noticed a lump at the very bottom of the scan. This led the doctor to refer my Dad to a urologist, who ordered an MRI in the abdomen region, which revealed a fist-sized tumor that had been growing on one of his kidneys for years. After getting a second opinion, the doctors decided to remove the kidney as soon as possible, thus surgery was scheduled for this past week.

I often hear that one of the reasons health care is so expensive is that doctors order "unnecesary medical tests" in order to cover themselves against medical malpractice lawsuits. While that may be the case sometimes, thank God that those tests were ordered this time. Normally, you don't discover kidney cancer until you find blood in your urine, by which time the cancer has spread throughout your blood vessels. For my Dad, they were almost able to save half of the kidney, but ended up removing all of it and found no other evidence of the cancer spreading. They left the major blood vessels intact and he's up and walking today (5 days later).

Modern miracles:
  • Magnetic Resonance Imaging (MRI) - It's expensive, but cheaper than death and allows doctors to see inside without cutting people open.
  • Specialization - the family practicioner, MRI technician, urologist, and surgeon worked together as a team and they saved my Dad's life.
  • Internet - I'm working from my Dad's house this week, and no one will notice a difference in my output. I can help him between naps, eat dinner with him, and mow his grass this weekend - without losing any work time. Without the Internet, I would have had to cut my trip short, leave customers and co-workers in a lurch, or use up my vacation for the year.

By the way, this reminded me that you can't replace the family and friends who you grew up with. If some of yours are getting older, please call or visit them today.

Tuesday, August 15, 2006

Troy Evans, Former Bank Robber

Last week I spoke at the Society of Government Meeting Professionals' Southeast Regional Conference in Ft. Meyers, Florida. If you've never been to the southern Gulf coast of Florida, I highly recommend the Sanibel Resort.

The keynote speaker on Tuesday morning was Troy Evans, former bank robber. I had the pleasure of sharing a van ride with Troy from the airport to the hotel, and we ate lunch together on Tuesday. Never heard of him? You will soon; the movie rights to his life story were just picked up by Hollywood while A-list actors line up to play his part.

Troy grew up as a good kid in middle-class Phoenix, but turned to drugs, and then took to bank robbing to support his habit. This landed him in the federal penitentiary for 7+ years, during which time his son grew up, he cleaned up his act, and received two college degrees. He's a professional speaker now, spending half of his time teaching banks how robbers like him think, half teaching kids about the dangers of drug use. It inspires me that in America, you can mess up as badly as Troy did, and bounce back to heights beyond anything you could have achieved had you lived a "normal" life in the first place.

The other keynote speaker was Jon Gordon, energy coach. This guy has a head cold that would have kept me in bed, and he still manages to jump on stage (literally) at 8am and motivate us all to attack our day with positive energy. The conference organizer, Beth Miller-Tipton from the University of Florida, definitely headed his advice as she effused praise about our speakers and topics for the conference.

Friday, August 04, 2006

What I learned about customer service in France

Last week, I spent 9 wonderful days in Paris and Normandy. I love the French towns and countryside, but I found the customer experience with their service industries to be less fulfilling.

We took the train to the airport our last day, and exited into Terminal 2. This was a wild guess on our part, since the signs didn't list anything about the differences between the various terminals, such as which airlines are there or if the terminal has domestic or international flights. We walked to the information desk and said, "We're trying to find American Airlines."

The agent replied, "Why did you get off here?"

"Umm, well, we didn't know which terminal to enter."

"Well, American isn't here. It's in Terminal 3."

The agent promptly looked down, ending the conversation. I had to then ask, "How do I get to Terminal 3?"

The agent replied without looking up, "You can take the train or the bus."

I'd already been on the train, so I asked, "Where do I find the bus?"

Apparently I had exhausted the limit of the agent's patience, so he just waved his hand to the right and said, "Over there."

It's probably a cultural difference, where the French expect you to be able to solve your own problems. But I realized that I've come to expect excellent customer service, where the customer's problem becomes the supplier's problem. I expected that the information agent would have understood that I must have been lost, otherwise I wouldn't have come to him in the first place, and I expected that he would provide a solution from start to finish, rather then just answering my questions one at a time.

I see both good and bad customer service in America all of the time, unfortunately, even in my own company. This experience led me to crystallize some of my thoughts about what I hope our company will offer it's customers.

  • The fact that the customer contacted you means they have a problem.

Even if you've seen this mistake a thousand times, it's likely the first time they have encountered the situation. Always start with the assumption that the problem is real and that you can help them.

  • The customer is the most important person to themselves.

When you provide service, the customer should feel like they are the only person in your world, and that their problem is the only one you are working on. This will never be true, but they deserve that level of respect and focus while you are communicating with them. It makes me cringe when I hear a service representative say "We're really busy right now with a lot of other customers" (i.e., "you're less important then them") or "I haven't been able to get to that because I'm working on another project" (i.e., "I'm too busy to deal with your issue"). This leads to the next point:

  • Your problems are not your customer's problems.

Good service means that you focus on listening to the problem, document the issue, and either provide a resolution or an estimate of the solution delivery time. And you should do this without trying to pass your problems or your other customers' problems off as excuses against delivery.

  • The customer needs a solution, not an answer.

Instead of giving simple yes/no answers to the customer's questions, or providing a standard solution from a list of FAQs, I try to listen for the root problem. Often, customers ask questions that are symptoms of the real problem, or that are just plain the wrong questions to ask. Don't answer their question right away; take the time to drill-down to identify the problem, and then provide a solution, which should anticipate follow-up questions and issues.

  • Communicate and follow-up.

Excellent service keeps the customer informed of the progress on their issues, and follows through with the customer after providing the solution in order to make sure that it met their needs. This sets the stage for a good working relationship when the next issue arises.

  • Be nice. Be polite.

On the flight home, the American Airlines attendant had the happiest face I'd seen all week. She looked me in the eye and smiled when she asked me questions, and used "please", "thank-you", and "you're welcome" liberally. Personally, I think that "you're welcome" is a phrase of beauty that is being destroyed by "no problem".

  • Be honest. Be fair.

When I mess up, I fix it. And if I've caused you financial loss, I offer to share it. If I promise that my service will be available 24/7 and it's interrupted for 8 hours, then I think that a 5% reduction in your monthly service bill is appropriate, i.e. 1 workday lost out of 20 for the month. The customer would rather have paid the money and not had the problem, but this is both a gesture of fairness and a way for me to quantify the financial cost of my mistake, so that I can justify any financial investments required to prevent it from recurring. (Note that this is the way that I would run a business, but it doesn't reflect the policy of any company I've ever worked for.)

  • Charge the customer enough so that you can profitably deliver the service they need.

Everyone tries to keep costs down, but sometimes this can be counter-productive. If I have to service 50 accounts, then they are each going to get, at the most, 2-3 hours per month of my attention. If this is not enough, then reduce your number of accounts and increase your support fees so that you can provide superior service. I saved this point for last, because it is often the root problem when a service agent does not meet the above points. If you have fewer accounts, then you can focus on individual problems, you won't have to pass excuses about being over-worked, you won't be mean becuase you are stressed out, and you'll be fair because you aren't operating on razor-thin profit margins.