A fundamental challenge in evaluating software is to look beyond the user interface. After all, this is the only part that most users will see, and it’s what does the things they care about. So it’s naturally the focus of their attention. But a product can have the right features and still be the wrong choice if it can’t handle the required data volume, number of users or integration with other systems. Unless such factors are examined in advance, buyers easily can purchase a system that fails to meet their needs.
Hosted systems pose a particular risk. Buyers often do not look at the technical details as closely as they would if they were going to run it themselves. Yet hosted vendors must avoid customization so they can share one program among many clients. Of course, hosted products do allow some tailoring by individual customers. Though the depth of this tailoring varies considerably across products, it often is limited to superficial alterations such as field labels and screen layouts.
Eloqua Conversion Suite (Eloqua Corp., 866/327-8764, www.eloqua.com) raises these issues not because it’s a bad product, but because it’s such a good one. Eloqua is a hosted system designed to help companies gather and nurture leads that will be passed on to a sales force. Features such as automated multi-step campaigns, personalized e-mail and Web pages and integrated tracking of e-mail and Web behavior are so attractive that it’s tempting to consider the system for managing ongoing customer relationships as well. But Eloqua is designed to complement a customer management system, not replace it. Despite its attractions, it lacks some capabilities needed to stand by itself.
Let’s look at the good things first. Eloqua’s strongest feature is its campaign definition interface, which manages complex, multi-step, cross-channel work flows. This feature, which Eloqua calls Program Builder, lets users create process diagrams and define what happens at each step. Users can pick from a long list of possible actions, such as selecting names from lists, sending different messages, adding or updating data, waiting a specified time period or reacting to a response. In addition to the start and end dates, actions can be assigned execution periods such as business hours or workdays. This lets the system respond differently depending on when an activity occurs, such as referring leads to the call center only when the center is actually open. Processes can follow alternative paths when a primary activity is unavailable.
Eloqua defines the available actions. Users who need a new action must ask the vendor to build it. The system does adjust automatically to user inputs, such as listing the customer’s own e-mail forms as options for an action to send an e-mail.
Users can import HTML e-mail forms from outside of Eloqua or create reusable e-mail templates within the system. Templates can incorporate contact data stored in Eloqua and may include links to other Web addresses, images or Eloqua forms. An optional module, called Hypersites, creates Web pages whose contents vary based on user-defined rules. In Eloqua’s example, a travel site displays different offers depending on the viewer’s home city. Each set of offers must be defined explicitly during page set-up. This is more work than automatically pulling offers with a database query and will impose some constraints on the sophistication of the Eloqua marketing programs.
Work flows are defined largely in terms of lists. Contacts may be added or excluded from lists based on attributes such as title or industry, on system-captured behavior such as Web page views, on actions such as replies to offers and on previous messages received from the system. List membership can be fixed when a list first is created or be updated automatically as new data appear.
Eloqua uses e-mail address as the main identifier for individuals. Each address appears only once on any list to help avoid duplicates. Anonymous Web visitors are tracked based on Internet Protocol address, which often indicates location or company. Some treatments can be tailored on this basis, such as geographic targeting or excluding competitors from lists. If Web visitors later give an e-mail address, their previous history will be linked to their new record.
Along with contacts and anonymous visitors, Eloqua’s data structure includes tables for companies and a log of events such as Web site visits and messages sent. But the system lacks tables for purchase transactions and other events that originate outside of Eloqua. Nor can users add such tables. Somewhat similarly, the system does not capture marketing campaign costs or revenues.
These limits reflect Eloqua’s hosted business model, which makes customer-defined tables difficult to allow, and its role as a lead management system. Eloqua assumes that transaction history and campaign results will be stored in other systems with a comprehensive customer view. Eloqua only needs to integrate with such systems by sending them copies of Eloqua data and importing data they provide. Existing connectors allow more intimate integration with Salesforce.com and Microsoft CRM.
Eloqua does provide reporting on its own data, including statistics on work flow activity and e-mail measurements such as numbers sent, delivered, read and replied to. A Chat module uses rules to determine when to offer Web site visitors an online chat. This module includes an agent interface that displays the visitor’s history, manages the chat session itself, captures results and allows follow-up activities such as sending information and adding the visitor to an Eloqua campaign.
Pricing is based on modules purchased, number of Web and e-mail contacts and number of users. A basic offering, Eloqua Express, provides e-mail and Web activity tracking for $20,000 to $30,000 yearly. Most of the firm’s 170 clients pay $30,000 to $80,000 yearly. Eloqua began business in 1999 and has U.S., Canadian and British offices.
