Everyone loves a good origin story* and Boxever has a classic: the company started as system to recommend add-on purchases on airline booking sites but found that prospects lacked access to customer data, so it pivoted to build customer databases. Similar stories are common in the Customer Data Platform universe but it’s the details that make each one interesting. So let’s give Boxever a closer look.
Boxever’s foundation is the customer database. The system can ingest data from any source and has prebuilt connectors for standard operational systems used by its clients (mostly airlines and travel agencies). Data can be loaded in real time during Web or call center interactions, by querying external sources through API connections, or through batch uploads. All inputs are treated as events, allowing the system to capture them without precise advance data modeling. But the system does organize inputs into a base structure of guests (i.e., customers), sessions, and orders. Clients can extend this model with additional objects such as order items. The system can usually classify new inputs automatically and flags the remainder for human review.
The system is exceptionally good at capturing the frequently-changing elements peculiar to the travel industry, including location (current and destination), weather (at the current and destination location), prices, available products (e.g. vacant seats and upgrades), loyalty status, and even current flight information. Most of this data is read from external systems at the start of an interaction, used during the interaction to provide context, and stored with the interaction records for future analysis. Again reflecting the specialized needs of travel marketers, Boxever sessions can include things like airport visits, flights, or stays in a location, in addition to the conventional Web site visits or telephone calls.
Boxever also provides extensive customer identification capabilities, both to support real-time interactions and to merge profiles behind the scenes. It can match on specific identifiers, such as a loyalty account number, on combinations of attributes such as last name and birthdate, and on similarities such as different forms of an address. It can assemble profiles on travel companions, who are often not as well known to an airline as the person who booked the ticket. It also calculates personal propensities to buy airline services and from specific partners such as hotels and retailers. These propensities are used to make recommendations.
All this data is assembled by the system into personal profile that includes attributes and an event timeline. The event timeline captures both customer actions and system actions, such as running processes or changing data. The timeline can be displayed to customer service agents or used as inputs for automated decisions. Users can also define segments and contexts using any data in the personal profile.
The decisioning features of Boxever are organized around offers. Users first set up templates for each offer type, in which they define the parameters required to construct an offer. Parameters vary depending on the channel that will deliver the offer and can include text, images, Web links, products and prices (which can be validated against external systems), and other components of the message to be delivered. Other offer parameters include the context in which it’s available and actions to take in other systems if the offer is accepted. Actual offers are created by filling in the appropriate parameters.
Offers are embedded in decision engines. These contain rules that specify when particular offers are available. The decision engines are connected to delivery systems through flows, which can react to requests during a real -time interaction, listen for an external event such as an abandoned shopping cart, or run a scheduled batch process such as generating a mailing list. A decision engine can be limited to a specific context and contain multiple rules, each with its own selection conditions and linked to an offer.
During execution, the decision engine finds all rules that the current customer matches. It can return all the related offers or a limited number. Offers can be prioritized in a user-specified sequence that applies to all customers, or they can be prioritized for the individual based on propensities or other scores. The system provides automated segmentation, predictive modeling, and testing to help find the best offers in each situation.
When you strip away the superstructure of offers, flows, and decision engines, the keys to all this are context and rules. Context can limit eligibility for an entire decision engine or a specific offer within an engine. Contexts are defined with a point-and click query builder that allows complex, nested statements. Rules are defined with a scripting language, which some marketers will find intimidating. The scripting interface does provide some assistance such as dropdown lists of available operators, segments, and code snippets. Boxever says some of its clients write their own rules and others rely on Boxever staff to write them.
Context is an especially powerful feature. It plays the role of what I usually call “state”: that is, a general description of the customer’s current condition that narroww the range of potential treatments. For example, a customer who is currently traveling should be treated differently from a customer who is planning a trip. But context in Boxever isn’t tracked as state-to-state movement within a comprehensive journey framework, as required by my definition of a Journey Orchestration Engine or JOE. Nor, despite the name, do Boxever flows specify multi-step message sequences. It’s possible to creates such sequences within a single Boxever decision engine but it would take some clever rule design.
Like most Customer Data Platforms and orchestration engines, Boxever leaves the actual delivery of its offers up to external systems. Flows can connect to email, text messaging, mobile apps, display ads and other systems. Boxever can also integrate with order processing, loyalty, and other operational systems. The vendor says a Web site integration can be completed in several weeks, while more complicated integration may take four to six months. A typical Boxever client has about a half dozen source systems and ten delivery systems.
Boxever was founded in 2011 and opened a U.S. office in 2014. Pricing is based on number of active customers or transactions. The company rarely works with clients having less than $100 million annual revenue. Most clients will pay well north of $100,000 per year. The company currently has 20 clients.
*I myself was found in an unobtainium-lined box clutching a mysterious amulet.