The Number One Feature Request from Meeting Planners

Jerry Chandler from Business Travel Executive magazine asked me, "What is the #1 feature request that you hear from meeting planners?" I've heard this question before, and I know that editors expect an answer like "Travel Integration", "Meeting Expense Consolidation", or "Budgeting". But my answer was, "Tools that will simplify their working life".

Deliver More. Do Less.

In business, everyone is asked to deliver more product with less cost. Since the "product" of Meeting Planning is often pre-event data management, this demand translates into managing more information while using less human time. Meeting Planners are flooded with data, and they each want "The Feature" that will make their unique work flow simple. For some, the feature is roommate matching; for others, it is financial integration for month-end accounting reconciliation; for others, it is managing seating assignments.

Developing "The Feature"

Software developers try to create an application with a set of features that meets the needs of the largest group in the target audience. In the late 1990s, online registration was "The Feature" that all event planners and attendees wanted, and providing it was (in hindsight) straightforward. Some events collect payment from attendees, so integrated online credit card processing became "The Next Feature". Then room block management was the feature, but only for a smaller set of event planners since not all events manage their room blocks. Roommate matching was the feature for corporate meeting planners whose firms wanted to reduce housing costs by sharing rooms among their employees. Of course, this feature was useless for trade shows and conferences where attendees stay in individual rooms. Next, corporate travel managers who found themselves in charge of centralized meeting planning decided that travel integration was the must-have feature, for one stop group travel planning (event registration, housing, and travel arrangements). The focus on meeting expense consolidation led to feature demands for Budgeting, RFP management, Facility / Vendor databases, and so on.

Along the way, each new feature made online event registration applications appeal to a broader audience, but somehow, more features made more people less satisfied. This contradiction is explained when you remember that each individual user did not specifically ask for all of these features, what they wanted were "Tools that will simplify their working life". With additional features, applications became more complex to master, and developers became focussed on expanding breadth in the application instead of tying existing features together to streamline individual workflow processes.

When More Is Less

The May 21, 2007 issue of Forbes reports that the Honda CRV, with 88 possible configurations, outsells by 250% the Chrysler Nitro, with 167,000 configurations. Since dealers sold only 36,687 Nitros last year, Chrylser and its suppliers were paying for an infrastructure that supported five times as many configurations as any customer wanted. (The 2008 Nitro will allow 680 option combinations.)

When I apply this logic to our application, I find about 16,549,457,379,840 possible combinations in our custom reporting area alone.

• 21 report types
• 7 report output formats
• 11 report display options
• 4 report visibility options
• 2 report data scope options
• 8 "Changes Report" options
• 10 "Role-based"options
• 11 group options
• 6 subtotal options
• Approximately 1000 columns
• 29 filter options, plus 2 date filter options with 9 date options and 34 date range options
• 2 header/footer options with 63 dynamic fields
• 3 export action options
• 10 custom column options

I've worked on this application since the first line of code, and there are few features or options that were added without solving a specific customer need. But after 8 years these features in aggregate have made life more difficult for some users than it should be. And it has created a "headwind" that slows down development; because each new feature can potentially affect more areas, QA must test more possible combinations in order to ensure backwards compatibility, and a wider audience demands more new periphery features that perpetuate the cycle.

Paid to Provide Solutions, not Just Identify Problems


While providing more features for the event planning industry, our design philosophy has to step back and create a User-centric (and Workflow-centric) focus on simplicity. I will continue this discussion in a future blog.

APEX TAC Monthly Meeting Minutes - May 2007

The APEX TAC held it's monthly Virtual Meeting on May 17, 2007. Here's what we did.

APEX TAC Monthly Virtual Meeting

Meeting Topic: APEX Virtual Meeting 5/17/07
Host: Rick Borry (Certain Software)
Meeting number: 484 360 851
Start Time: Thursday, May 17, 2007 07:57:17 PM
End Time: Thursday, May 17, 2007 09:09:26 PM
Meeting URL: https://newmarketinc.webex.com/newmarketinc

Attendee List:
Rick Borry (Certain)
EJ Siwek (CIC)
Jeremy Keller (Meeting Matrix)
Jane Melville, Julie Camp (Hilton)
Scott Rudberg & Andrea Campbell (Passkey)
Rob Wilson (Meeting Sites Resources)
Rick Fahnestock (MPI)
David Collins (Syllogy Design) - Joining the Rooming List Group
Michael Lu, David Quattrone (Cvent)
Charles Jeffers
Chip Meyer (Data App)

Agenda

STRATEGY BACKGROUND (from the Ft. Lauderdale Spring meeting):
See http://registrationdoctor.blogspot.com/2007/04/apex-implementation-pilot-q1-2006.html

PROGRESS UPDATE:

Jeremy Keller and Rob Wilson reviewed their progress on the RFP transformation tool. They are about 90% complete, but learned some lessons that we will adopt for the other groups:

• Generally, it's better to use the Response XML (OTA_HotelRFP_MeetingRS3.xml) because the Request XML sample does not have as much data.


• But even the Response XML document in the OTA standard is not complete - many fields don't have data or have duplicate data from other fields - this makes debugging very hard. We should modify the sample XML fiels so that all fields are complete and all data is unique (e.g. don't use the same name for Event Organizer and Key Contact)
• Rick and Chip suggested a "best practice" that Response Messages should echo back the data from the Request Message in addition to adding response data. This way the sending application could validate that the data it sent was placed into the correct fields, e.g. the Last Name in the meeting planner's application was stored into the Last Name field of the hotel's application. Hilton pointed out that this could lead to a lot of extra work and is really only necesary during the initial validation phase. Once the translator routine has been validated in both partner's applications, there isn't as much of a need to echo data back-and forth every time. This will be a discussion point during the initial pilot implementations.
• Jeremy added a CSS style tag to the XSLT so that he could color-code the font classes for "Labels" (from the APEX Template), "Data" (from the XML file), and "Comments" (his notes. We agreed to use this coloring standard during development.
• Jeremy uses Visual Studio instead of Altova Stylevision, which produces a lot of "extra" code in the XSLT. He manually cleaned up the output from Rob's Stylevision copy in order to produce the final transform.
• Rob noted that the data types used in the OTA standard are not always consistent, e.g. some dates are "Date-Time" type and others are "String". Chip noted that this may be intentional if the field can contain text such as "ASAP" or "3rd Quarter", but we need to review these issues and decide if they are mistakes or valid.
• Hilton raised several issues about labels, e.g. "Key Contact" in Section 1 but "Primary Sales Contact" in Section 5. The labels and amount of information collected must be reviewed for clarity and completeness.
• Hilton also asked about the location of the field definitions - since the RFP standard doesn't have an introduction (as the other standards do). For example, in Section 4, what is the difference between "RFP Published Date" and "RFP Distribution Date"?
• After Jeremy and Rob finish their merge, everyone will be able to add comments (in Red) to the final output for review in the Orlando meeting in June.
  

THIS MONTH’S TASKS:

• We will focus on completing the RFP XSLT and resolving its issues before tackling the other two schemas


• Jeremy, Rob, EJ, Chip will work on the RFP completion:
  


• Complete merge


• Update color scheme to match standard


• Review merged document and add comments, errors, questions


• Complete addition of data to all fields in RS.XML so that it is fully documented


• Rest of team should review the completed RFP with Rob and Jeremy's comments and make recommendations for changes needed, especially from the Hotels' prespective of what data they need to receive from Planners and send in response to RFPs


• Discuss common issues teams are facing and decide how to resolve them on the Forums at: http://apex.dataapp.com/Forums/tabid/226/ctl/Edit/mid/624/ItemID/6/itemindex/0/Default.aspx

NEXT MEETING (Orlando, FL after HITEC, June 27-28)

• Meeting calendar available at: http://apex.dataapp.com/Calendar/tabid/224/Default.aspx


• The next face to face follows HITEC in Orlando. The TAC meeting will be held on June 27th and 28th, starting at 3pm on th 27th and ending at 3pm on the 28th.


• We have a room block of 5 for $149.99 each at Embassy Suites Orlando - Lake Buena Vista, 8100 Lake Ave., Orlando, Florida 32836. Attendees can call the main number 407-239-1144 and ask for the Reservations Dept. (Mon-Fri, 8-4pm). Please have mention "CIC/APEX".


• Tentative Agenda:

1. Powershop beta demonstration (Chip Meyer)
2. XSLT Demonstrations by RFP team and review of work completed and recommendations
3. Close out RFP, focus on Rooming List and Event Specification Guide

End Note

Yes, even Pre-Kindergarten has graduation. Congratulations, Izabella!

2007 SGMP National Education Conference

On May 3rd I presented an educational seminar titled "Online Registration for Government Meetings: Compliance, Security, and APEX Standards for the Group Travel Industry" at the Society of Government Meeting Professionals (SGMP) 2007 National Education Conference in Atlantic City. You can wait to learn about the session in the next issue of Advantage magazine, or read about it below.

Session Summary

This session discussed the past, present, and future of online registration. Event registration in the past made meeting planners the bottleneck in a cumbersome process as paper, phone, and fax registrations came in and were typed into a computer, while attendees waited for their confirmation letters to arrive via mail. We demonstrated features of modern online registration tools that provide a cost-effective path to attractive web sites, custom registration forms, integrated credit card processing, and instant email communication. Online registration is governed by many regulations and best practices, including data encryption using Secure Sockets Layer (SSL), Payment Card Industry (PCI) compliance for credit card processing, American Disabilities Act (ADA) Section 508 compliance for equal opportunity, Fair and Accurate Credit Transactions Act (FACTA) regulations for privacy concerns, and the CAN-SPAM law for e-mail communication.

Lastly, we discussed the APEX initiative to produce open standards for electronic data transfer of event RFPs, rooming lists, and Event Specification Guides between meeting professionals and hotel suppliers. During the Q&A period, we discussed an analogy for the future world of instant and easy data exchange between hotels and meeting planners; APEX will be the un-seen plumbing in your housing, while software tools will be the faucet handle in your sink – offering a simple and intuitive way to get water. I encourage participants who wish to remain informed about the topics discussed in this session to subscribe to the speaker’s blog at www.registrationdoctor.com.

Listen to Your Customers and You Might Learn Something

Sclerochronology is the study of physical and chemical variations in the accretionary hard tissues of organisms, and the temporal context in which they formed. Familiar examples include annual bandings in reef coral skeletons or daily growth increments in mollusk shells.

I learned this from our customer Beth Miller-Tipton of the University of Florida during a conversation at the Society of Government Meeting Professionals in Atlantic City last week. Beth also taught me that she is using our product to manage abstract submission for their upcoming Sclerochronology conference. This was news to me; I didn't know that we had an abstract management tool.





Behind the Curtains at Scientific Conferences

In my graduate school days at Berkeley I had the opportunity to help organize a few conferences for the California Catalysis Society. Scientific conferences typically have a higher ratio of speakers to attendees than other educational events. Let's say you're an expert in a particular area of science (such as Catalysis or Sclerochronology) and you find yourself appointed to be the host of a conference on the subject. When you begin to put the program schedule together, the first step is to issue a "Call for Papers", which you send to everyone in your field. Scientists, professors, and students who want to present their work at the event submit abstracts describing the content of their proposed presentation or poster. A conference usually has multiple sessions, each focussed on a particular topic. The session chair is an expert on that topic and has the job of selecting speakers, moving the presentations along (often only 15-20 minutes are allotted per speaker), and managing the discussion.

Presenters submit these abstracts for many reasons - their budget might not allow them to travel to the conference unless they are speaking, they may have recent results that they are about to publish and want to generate additional attention for their research, or they may be rehashing previous research in order to get another line on their Curriculum Vitae (the scientist term for resume and list of publications). Success in science, like most fields, is a combination of quantity and quality. Quantity of research is demonstrated by the length of your list of publications and presentations, while quality often depends on the number of citations that your research has, i.e. the number of other people whose work references yours. (Where do you think those guys at Google got their "page rank" idea?) These two factors combine to help determine your funding levels from grant applications, your promotion to tenure, your movement up the academic ladder into the elite universities of highest prestige - you get the idea. So getting your abstract selected is a big deal at some conferences.

Abstract Management Process

As the meeting planner, you have to collect the abstracts from prospective presenters, force the session chairs to review the abstracts and select their posters and presentations, and keep the presenters informed of their status (since many presenters cannot register or make travel plans until they know that their abstract will be accepted). Fortunately software is available to facilitate this process, although dedicated "Abstract Management" solutions can be expensive and are over-kill for many conferences.

Certain Registration Extended

Enter our clever customer Beth Miller-Tipton. She devised a process with her IT department and Certain Registration to use her existing registration system to collect both abstracts and registration and housing reservations. They first upload the abstract file (usually as a Word document or PDF) onto their internal servers, then link to a registration form in Certain Registration, where they collect the presenter's contact information, abstract title, presentation preferences, and so on. They use data integration to pass the web address of the abstract file into the registration form, so that they can produce a single report from Certain Registration with the contact information for all submitters, with hyperlinks to their abstracts. Beth and the session chairs sit down one day, run through this list on a projection screen, and click on each link to view the abstract. The chair (or committee) quickly decides which abstracts to accept for presentations, or which for posters, or which to decline if space is limited.

Without having to learn a new system or spend a bundle, Beth created an online abstract management process that works conveniently for everyone - the meeting planners, the session chairs, and the prospective presenters. I liked it so much that we decided to add a new custom question type ("File") into Certain Registration, so that she can manage even the file upload portion of the process within one system. Hopefully, many other customers and prospective customers will find this to be equally valuable.

Neat Technology

I've spent a few hours recently with Maged Mohamed, CEO of TechNeat. They created an interesting twist on the barcode / mag stripe / RFID badge readers that are common in trade shows and larger events. TechNeat builds their products on top of the Blackberry wireless platform, so data captured on-site at an event is available online immediately. Compare that to the normal method of capturing data on a local network or hand-held device (or on paper, heaven forbid!) and you discover many advantages and some potential new applications.

A Brief Background on Badge Readers

If you've attended a trade show in the past 20 years, then you are familiar with badge readers. Attendees get a name badge printed with their name and a bar code, magnetic stripe, or (more recently) RFID chip. They walk around the show, look at exhibits, and if they find a product of interest then a sales rep scans their name badge with a hand-held or table-top device. Each scan tells the exhibiting company who you are, and after the show the exhibitors either print out your information or take a memory card to the services counter in order to download the data in an electronic format.

Due to technology limitations, a name badge that is 3-4 inches wide can store about 20 characters with "1D" (one dimension) bar codes, about 225 characters (3 tracks with 76 characters each) with a magnetic stripe, 12 characters in an RFID chip, and practically any amount of data in a "2D" (two dimension) bar code (although the bar code will increase in size with the amount of data printed). Thus, except for with 2D bar codes, name badges usually only store a unique identifier for each person, and the full contact information is stored in a registration database with a link to that unique ID.




TechNeat Products

TechNeat supports all of these badge formats, but their products are scanners built upon the same wireless Blackberry devices that currently addict so many techies. When an exhibitor scans your badge at a show, your unique Id or contact information is immediately and securely transmitted via the Blackberry's wireless carrier to TechNeat's Internet servers. There, they record the details of the interaction (date-time, scanner id, etc.) and link the registrant's unique ID to their full contact information. Thus employees who are not at the show can sit at their browser anywhere (with an Internet connection) and watch the leads come in from their colleagues who are exhibiting. When the show ends, the exhibitors simply drop off their scanners and head home, which sure beats standing in line for an hour waiting to pick up a 3.5-inch floppy disk.


Integration Opportunities

While I'm a fan of Techneat, I don't get paid to sell their products, and so the chance to interact with their systems (and customers!) is most exciting to me. For example, registration workers at the front desk in a location without ethernet or Wifi Internet access could welcome attendees, scan their badge, and instantly transmit a signal to our registration database that the attendee has checked in for the show.

Or, if you need to know who is going to each of your sessions at a large event, then you can put TechNeat's RFID scanners or floor-mounted bar code readers at the doors to your meeting rooms. As attendees walk through the door, the scanner reads their registration ID and transmits it and the scanner's ID to their online database. By connecting a scanner ID to a specific room and the registration ID to a person, we can record who went to each session and when they entered and left the session.


Future Potential

I love working with companies, like TechNeat, who find better ways to collect information at an event while we work on producing better ways to organize and manage that information before, during, and after the event.