Pros Seek Prosynch Solution

By BTN / April 22, 2001

Pros Seek Prosynch Solution

During a period of turmoil in travel distribution, the maintenance and updating, or synchronization, of multiple traveler profiles is proving to be a nightmare for much of the corporate travel community.

While such buyers as Terry Sullo of Akamai Technologies in Cambridge, Mass., wish profile databases could be matched with the push of a button--like the desktop synching of a PalmPilot--the reality is far more Byzantine. The issue is even more complicated when senior management mixes in a merger, as was the case for Credit Suisse First Boston's assistant vice president of corporate travel Valerie Dickson. These buyers last month joined vendors Chip Mahan, director of U.S. technology sales for American Express; Steve Reynolds, general manager and chief technology officer at TRX Inc; Dave Wood, president and CEO of Trondent Development Corp.; and BTN executive editor Jay Campbell to discuss the issue.

BTN: Please characterize what's so problematic about profile synchronization.

Wood: The big problem now is that depending on the relationships between the agencies and corporations and the booking agents, everyone has their own idea about who owns the profile data and where the control of that needs to be.

Dickson: We are frustrated with so many different products having it. Do we go with our online product to do it or do we go with our agency to do it? How do we get it done and what is the best route? Also, I think the profiles having to be so standardized is virtually impossible. I don't know about other companies, but unfortunately we are not standardized. We support our parent company's different pieces of business and we don't all have the exact same requirements in our profiles, and that's a challenge.

Mahan: It's the age-old question of which database, or which copy, is the current, updated copy. We've got to maintain potentially multiple systems, but the ultimate goal is to get to this "master profile" and the question then really is--and this is where you find some disagreement--where does that master profile info reside? Not only that, but how does it interface with both interactive tools and traditional processes. Our clients really want to own the data and rightfully so. One of the things that we're seeing is that the client is striving to have their HR system be the driving factor for basically updating the profile and passing profile-type data. And we agree with them. We agree that these ERP systems--the SAPs, Oracles and PeopleSofts--ought to be sharing or passing that data. And I don't think the amount of data that's being maintained today is really necessary in a GDS.

Reynolds: The systems today exist just because we still have one foot in this legacy world of GDSs and back-office accounting systems that were built in the 1970s and '80s and we've got this other foot in this Internet world, where there's booking engines and supplier directs and that kind of stuff. So the synchronization process is all there just to facilitate that transition and there's really no need for synchronization if you could just pick any master for the data. That's what everybody is struggling with. The answer has got to come from the company and the individuals themselves, but the next question is just where do you start? The booking engine is a good place, the ERP system is a good place. I think, at the end of the day, the ERP system will have very robust profile information on its abilities that will "synch up" with a booking engine that actually creates the reservations and that'll be the master. We do a lot of synchronization with the agency side of things with the GDSs, but I think long term, that's probably not where the best money is to be spent.

BTN: How have profiles traditionally been maintained?

Sullo: Well, exactly what is the profile? What do we use it for? It appears that the agency historically has used the profile as a means to service this person with little comments they have thrown into the profiles. One of the reasons this is so difficult is that everyone does it in a different way. Now, buyers don't understand that although they are building a profile in their self-booking system, it's not automatically going to be pulled into the GDS. And if you make a change in the GDS profile, it's not necessarily feeding back. At this moment, the data has to reside in multiple places. The GDS, unfortunately, is still king, whether we like it or not. Corporations think that because they've got the HR module, they can create this universal profile that automatically goes into the GDS, automatically goes into the self-booking system and any time that the traveler wants to make a change, it automatically appears everywhere. That's what they think, but that's not what's happening.

Reynolds: We put it in the GDS today for convenience and once it's in the database, that becomes the master. But there are no standards in place, which is why the GDS hasn't been able to become the master for all this data. It's free form text, which can be anything you want, any format you want, so you're kind of held hostage. What's unfortunate is that all these agencies have spent years doing data entry into the GDS and then there's no value there--it's just crap.

Mahan: So then you move away from that type of environment and into what we're all developing in terms of a two-way profile synch database that has certain standards. Then you basically update that regardless of where the interface is coming from. Eventually, our goal is to get the GDS out of having any profile data at all, so we won't be updating the GDS.

Wood: We take a different view of the ownership of the data than TRX or American Express. The master source of the data is going to be in a variety of different places, either GDS or booking or HR data. But not all agencies have the financial and human resources at their disposal as American Express. And you can't shy away from the fact that there are going to be some agencies and corporations where data is going to have to reside properly in some controlled manner in the GDS. The traveler is not going to use an online booking engine exclusively, so he makes a change to his online profile. He makes his trip and everything is all fine, but then two weeks later, for whatever reason, the online booking engine is inconvenient to him so he calls his agent and then he gets upset because the credit card number that he put into his online profile is not available to the agent, "Well, what do you mean you don't have it, I just entered it!" He shouldn't have to be concerned with the fact that there are different systems. We need technologies that are going to allow that information to be everywhere it needs to be.

BTN: And is that available today?

Reynolds: Well, not completely. I could use a booking engine and make a change to my credit card, and then that change is going get pushed into the GDS to be used by the agent. It may not be implemented.

Mahan: It's not available on all booking engines.

Dickson: It's a challenge. I have a global product and I can't use the profile synch product globally, so I won't do it if I can't do it in all the regions that I have the product.

Mahan: I don't think that the GDS is the proper place to store it, mainly because there is no data standard. It's free form, so it's very difficult and very challenging to keep that as a standard. The second side of that is from an operational standpoint: Whenever you have startups or conversions, mass-enrollments, etc., you cannot really do that effectively today in the GDS. Say I have a contract and today I'm using Apollo and then I want to go to Sabre. I don't want to have to recreate all those profiles all over again. So today that's a significant challenge, whereas if the agency owns the profile data it doesn't matter.

BTN: So, then, the goal is two-way synchronization?

Mahan: Yes, because the ultimate goal is one would want to use the profile database as the master. Until we completely get out of the GDS, we're going to have two-way synchronization to keep the both of them up to date.

BTN: Is there a way that the traveler can update the master?

Mahan: Good question. Today, no, but one of the things we're working on right now is a Web interface so that the traveler and/or the agent would have that ability. Basically, the goal is to get out of the GDS completely.

Wood: I don't think you're ever going to completely do away with the GDS because there are some travelers that are quite put off if they're on the phone with an agent and say, "I've got this new credit card number that's got to get in there," and the agent says, "Sorry, I can't service you, you have to go to this Web site." It just becomes an inconvenience for a traveler if that traveler is used to being serviced by the agent and they're now being told, "Sorry, I can't help you."

Reynolds: Why would the agent tell them that?

Wood: Not all agencies have the resources of the large ones. They're not all going to have point-of-sale tools or access to the Web or a lot of other things that you're used to. The only way that they're going to get that data entered is if they keep referring to the GDS.

Mahan: So what happens when I start having a direct link outside of the GDS to do my bookings or direct sale?

Wood: It's still going to be a problem, and we're a ways off from an agency directly bypassing the GDS, unless you're talking about an online booking.

Dickson: It adds another challenge when we get to that.

Reynolds: Just to touch on Dave's point, with the agencies that use our product, a traveler might call up and wants to make a profile change. The agent will make the change for that reservation and then will instruct the traveler that if they want to make this permanent, to go online.

Wood: That's my point. That's an inconvenience for the traveler. You're not going to tell some highly paid executive whose time is valuable that, "Sorry, I can't help you," or, "I've got to inconvenience you more for whatever reason, go to this site and do it yourself."

Dickson: That is what we're going through right now. We do tell them we'll take it for that one booking only, we do tell them that they need to go to a site. We have been doing this since December now. They have been receiving it okay, but it does present some problems. But we also need the agency to be able to make that change for us, which they can now only to a certain extent. When we went to the online profiles we had just gone through an agency transition, so we took all our data from the old agency to our vendor.

BTN: Would you do that again?

Dickson: I think we would. We would take some different steps in how we did it, but we had some real challenges because at the same time, we had the merger with Donaldson Lufkin and Jenrette, so we had some challenges because they had another GDS. You name it, it happened.

BTN: How did you resolve that?

Dickson: We standardized the files from DLJ as best we could and we went out to travelers and travel arrangers and asked them to update as much as they could. The profiles that we received from the DLJ travelers did not have the same MIS content that we have on the CSFB side. We also fed in HR data to take care of a lot of the other information.

Reynolds: Another thing we've found is that the profiles are expanding dramatically. It's not just my frequent flyer number, my credit card number, my accounting codes. It's all the purchase history for the traveler, it's all the touch-points, it's all the e-mails sent, every phone call made. It's all this other stuff that you tend to get if you buy something from some dot-com Web site. I am starting to see some things happen that could potentially create the ultimate customer relationship management applications. We have a CRM application in our customer care group. So if you have purchase history for a corporate traveler, for example, there's a huge savings if you knew that this traveler 90 percent of the time did not refund his tickets. You know, "Every time I go to New York, I stay at the same hotel. Why do I have to keep telling you every time?"

Dickson: We do have a section where, if we ask them to, agents can track what they have learned over time. It may be something that the traveler or the arranger wouldn't tell you, but that every agent who picks up that phone needs to be aware of. We completely rely on the agency for service. If it's one of our VIP travelers who has special approvals, we need agents to unfortunately manually manage that process for us. It's not something we want out there in our database. Sometimes it's something we don't want the traveler to know that we have noted, or we don't want someone else to know that this one person doesn't require any approval. It's sensitive information, as with anything else we keep.

BTN: Someone suggested in a previous story that we ban travel agents from having access to the profiles so they don't mess them up.

Mahan: The value the agent brings is much greater than providing text or data entry, but one can argue that the same is true on the traveler's side. That brings me back to my original point, that we really think the HR system needs to drive the data. Now you won't capture everything out of your HR system, but certainly the bulk of the profile skeleton. Do you allow the agent then to never touch the profile? I think that the answer to that is no.

Reynolds: Yeah, I don't think this is futuristic technology. In the typical implementation of a booking engine, a huge chunk of the data comes from the ERP or HR, the credit card feeds into the profile database and then you have the traveler do the rest. If he wants his frequent flyer number in there, he goes in and enters it. So the company is the master for all that data, and then you have the individual as the master for something that's personal to them and their preferences, their seating preferences, meal preferences, etc. As far as the policy goes, that's all up to the administrator of the application. That might be the agency, that might be the company, wherever that resource is, wherever that can be obtained.

Sullo: We want travelers to think, "This is my profile and I am going to keep it up to date because it means I'll get the right services." When you put more of a responsibility on them, not just for frequent flyer numbers, that's something they see as a benefit. But they can't add everything. They don't even know their department numbers.

More