III - Mass Market Customer Relationship Management

By Gernot Starke.

MaMa-CRM takes the burden of (usually paper-based) customer contacts from organizations working in mass markets, like insurance, credit-card providers, mobile telecommunication providers, energy and water providers or large real-estate companies (in MaMa speak these are called «Mandator»)

It has been initially ordered by an independent mid-sized data center to support the launch of the German (government-enforced) e-Health-Card - and later on used to support campaigns like telephone billing, electrical-power metering and similar stuff.

For every mandator, there is at least one completely independent MaMa-CRM instance running, which is specifically configured for its mandator and a campaign.

MaMa-CRM architecture documentation is quite heavy in the requirements part, describing several aspects of flexibility that triggered many central architecture decisions.

The team that built the system consisted of 7-10 persons working in 2-4 week iterations for about 15 months.

Me (Gernot Starke) had the honor to be part of that team in a responsible role. The original client allowed me to talk and write about the system without disclosing the company name. I was not allowed to use any of the original documentation or source code.

Thanx to Thorsten, Sven, Arno and a few unnamed other guys for great cooperation and a successful finish.

III.1 Introduction and Goals

This document describes the MaMa-CRM platform, a software product family to coordinate processes between mass-market-service-providers and their clients. MaMa-CRM provides the foundation for individual systems, which have to be customized or configured for specific CRM domains.

MaMa-CRM has been built and is being operated by an innovative datacenter (let’s call it InDAC³) – a company providing a variety of hosted software services to its clients. Within business process outsourcing initiatives, InDAC is operating specific instances of MaMa-CRM for its customers.

Let’s clarify MaMa-CRM’s scope with a few brief examples (you’ll find more details in the requirements overview):

• Telecommunication providers offer new or updated tariffs to their customers. These have several possibilities, like email, phone, letter or fax, to respond or issue support queries regarding such offers.
• Retail organizations send specific advertising or marketing material to certain parts of their customers. Again, these can react on several different communication channels. These kinds of advertisements are called target group marketing.
• Insurance companies propose modifications or enhancements of existing contracts to specific customer groups. Insured persons or organizations can react over different communication channels, like phone, mail, email or even in person. In case they accept this proposal, they have to submit a legally binding signature.

The following figure shows a generalized overview:

In that figure, the mandator represents an arbitrary company or organization serving mass market customers. MaMa, our system, can host CRM campaigns for many different mandators from different industries.

1.1 Requirements Overview

MaMa-CRM controls customer relationship CRM campaigns, which InDAC (the contractor of MaMa) conducts for his mandators. InDACs’ mandators are companies like insurance or telco enterprises – which themselves offer services or products to mass market customers. These mandators outsource their CRM related business processes to InDAC.

MaMa-CRM shall support the following campaign types:

• Changes to tariffs or contracts for insurance companies, telecom and internet service providers and energy suppliers. You’ll find a detailed example for this process below.
• Processing of billing information for call-by-call telephone service providers: Mandator submits billing data to MaMa, which coordinates printing, submission and support for the resulting invoices. Management or handling of payments is out-of-scope for MaMa-CRM.
• Management of binary images for credit card and insurance companies, which print cardholders’ images onto the cards to prevent misuse. The German e-Health card belongs to this type.
• Meter reading for either energy or water providing companies or large-scale real-estate enterprises.

As MaMa is the foundation for a whole family of CRM systems, it shall be adaptable to a variety of different input and output interfaces and channels without any source code modification! This interface flexibility is detailed in section 1.1.2.

1.1.1 Campaign Example: Mobile Phone Contract Modification

An example shall clarify the complex business and technical requirements to MaMa.

MoPho is a (hypothetical) mobile phone provider with a large customer base and a variety of different tariff options (flat fee, time-based, volume-based etc.). Some of these tariffs or tariff combinations are not marketable any longer (a shorthand for “MoPho does not earn its’ desired profit from them… - but that’s another story). Others are technically outdated.

In their ongoing effort to optimize their business, MoPho management decided to streamline their tariff landscape. Within a large campaign they contact every customer with outdated tariffs and offer upgrades to new and mostly more beneficial tariff options. Some customers get to pay less, but have to accept a longer contract duration. Others will have to pay a little more, but receive additional services, increased capacity, bandwidth or other benefits. In all cases where customers accept the new tariff offer, the formal contract between MoPho and the customer has to be updated, which requires a valid signature to be legally binding⁴.

MoPho intends to inform certain customers via printed letters of the new tariff offerings. Customers can react via letter, fax, phone or in person at one of MoPho’s many sales outlets. As MoPho’s core competency are phone services, it doesn’t want to bother with printing letters, scanning and processing replies, answering phone inquiries and dealing with other out-of-scope activities. Therefore they employ MaMa-CRM as an all-around carefree solution. Look at MaMa’s approach to this scenario:

The 9 steps depicted in that scenario need some explanation:

1. MoPho selects pertained customers from its internal IT systems. We’re talking about a 30+ million customer base and approximately 10 million of those customers will be part of this campaign. MoPho exports their address-, contract- and tariff data and transmits these to MaMa-CRM. MaMa imports this customer data.
2. MaMa forwards only the relevant parts of customer data to the print service provider (a «Partner»). This company creates personalized letters from address and tariff data, prints those letters and finally delivers them to the postal service (which ensures the letters finally end up in customers’ mailboxes).
3. MaMa now informs the call center (also a «Partner») participating in this campaign, so they can prepare for the customers reaction.
4. In the meantime the print service has delivered the letters to the postal service, which delivers letters to the customers. This is more difficult than it sounds: 1-5% of addresses tend to change within 12 month, depending on the customer base. Some customers refuse to accept marketing letters. The postal service informs MaMa about all the problematic cases (address unknown, forwarding request etc.), so MaMa can decide on further activities.
5. The customers decide what to do with the letter: There’s a multitude of options here:
   • Customer fills out the enclosed reply form and signs it.
   • Customer fills out the reply form, but forgets to sign it.
   • Customer does not understand this offer and sends written inquiry by letter.
   • Customer inquires by phone call.
   • Customer ignores letter and does not react at all.
   • There are additional special cases (customer is not contractually capable, has a custodian or legal guardian, is under-age, deceased or temporarily unavailable…).
6. Let’s assume the customer accepts and sends the letter back via postal service. These letters will be forwarded to the scan service provider (again, a «Partner»), which scans them and performs optical character recognition.
7. MaMa imports the scan-results from the scan service provider. Again, several cases are possible.
8. MaMa distinguishes between all possible cases and takes appropriate actions:
   • The form is completely filled and signed.
   • The form is completely filled, but customer forgot to sign.
   • Customer signed, but forgot to fill other important fields in the form…
   • If the form is not returned within an appropriate period of time, MaMa might decide to resend the letter, maybe even with a different wording, layout or even a different contractual offer.
   • Surely you can imagine several other possible options…
9. Finally, for every customer who accepted the changed tariff agreement, MaMa sends back the appropriate information, so the mandator MoPho can internally change the corresponding master data, namely contracts and tariffs and take all other required actions (activities in MaMa).

For the phone service provider MoPho, the primary advantage is the centralized interface to all customer interaction: All processes required to conduct this crucial campaign are handled by MaMa-CRM, without intervention by MoPho. Very practical for MoPho is the nearly unlimited flexibility of MaMa-CRM to import and export a variety of different data formats. This flexibility enables MaMa-CRM to easily incorporate new campaign partners (like a second scan service provider, an additional email-service provider or web hosting partner).

1.1.2 Campaign Configuration

MaMa provides the software foundation for campaign instances that have to be extensively configured to operate for a specific mandator with a number of specific partners.

The following section gives an overview of such a configuration for the MoPho campaign described in the previous section.

1.Configure client master data

Define and configure required data attributes and additional classes, usually this information is completely provided by the mandator.

This data (e.g. contract-, tariff-, offer- and other business-specific entities or attributes) are modeled as extensions of the MaMa base model in UML.

In the MoPho telecommunications example, this data includes:

• Existing tariff
• List of potential new tariffs
• Contract number
• Validity period of existing tariff
• Validity period of new tariff

2. Configure communication channels

• Define and exchange security credentials (passwords, certificates, user-ids).
• Determine contact address, especially for handling technical and process issues.

3. Define campaign meta data

• start- and end dates,
• target dates for specific activities,
• reply address for letters, reply email address,
• phone number for call center,

4. Define campaign activities

Campaign activities⁵ can be either input-, output- and MaMa-internal activities.

• Output-activities export data to partners or the mandator, e.g:
  • PrintLetter
  • DataToCallCenter
  • DataToScanServiceProvider
  • ResultsToMandator
  • ProductionOrderToCardProvider
• Input-activities import data provided by the mandator or partners, e.g.:
  • MasterDataFromMandatorImport
  • ScanDataImport
  • CallCenterImport
  • SalesOutletImport
• Internal activities define data maintenance operations, e.g.:
  • Delete customer data 60 days after completion.
  • Delete all campaign data 120 days after campaign termination.

5. Model campaign flows

What is the required flow of activities, what needs to happen under which conditions (including plausibility checks).

1.1.3 Activities Subject to Charge

Some activities result in charges, for example:

• sending letters via postal service results in postal charges
• producing e-Health cards results in card production charges

As we are talking about potentially millions of clients respectively activities, these charges will amount to a significant flow of money:

Instead these are handled parallel to MaMa-campaigns by InDACs’ finance department⁶.

1.1.4 Additional Requirements

Status and Financial Reporting

MaMa has to campaign reports containing all campaign activities and their results (e.g. how many letters were printed, how many calls from clients were processes in the call center, how many clients sent their return letter etc.)

It’s especially important to report about activities subject to a charge (aka having financial consequences). Although MaMa-CRM is not responsible for the resulting billing and payment processes, mandators and partners need reliable and trustworthy reports about such activities.

MaMa shall offer adequate standard reports covering these cases.

Client Data Belongs To Mandators

MaMa-CRM follows a very strict data protection policy: All data processes in campaigns is somehow related to clients and needs to be kept strictly confidential. Mandators always remain owners of all such data, from whatever partner it is transferred to MaMa by whatever activities.

After a campaign officially ends, all (!) data including backups, configurations, data and metadata needs to be deleted⁷.

1.2 Quality Goals

1.2.1 Flexibility First

Simply stated, MaMa is a data hub with flexibility in several aspects: It imports data (aspect 1) coming over various transmission channels (aspect 2) executes a set of specific business rules (aspect 3) to determine further activities to be performed with this data. Such activities consist of data exports (aspect 4) to certain business partners (like print-, scan- or fax service providers, call centers and the like).

MaMa has to be flexible concerning all these aspects.

Aspect 1: Flexibility in Data Structure and Format

MaMa always deals with variants of clientdata - the most simple version could look like an instance of the following class definition:

1 public class Client
2   String primaryKey
3   String lastName
4   String firstName
5   Date birthDate
6   String title
7   Address postalAddress

MaMa needs to import such data from various campaign partners. These partners operates their own IT systems with their own data formats. They will export the affected data records in some format (see below) of their choice. MaMa needs to handle many such formats:

• Comma separated value (CSV): attributes are separated by a (configurable) delimiter, e.g.: “id01”, “starke”, “gernot”, “23-jul-1963”, “willi-lauf”, “D-50858”, “cologne”, “germany”
• Field order and delimiter can vary.
• Elements could be enclosed in either “ or ‘ or even «».
• Fix length formats, where every data record has a fixed length. Shorter entries are padded with empty strings or zeroes.
• XML dialects, either conforming to an appropriate schema or DTD.

Regardless of format, data elements need to comply to validation or plausibility rules. Good news: No serialized objects from programming language runtimes (e.g. from a java virtual machine) have to be processed.

Aspect 2: Flexibility in Transmission Formats and Modes

MaMa needs to handle the following transmission-related aspects:

• Standard transmission protocols (ftp, sftp, http, https) as both client and server
• Compressed,
• Encrypted
• Creation of checksums, at least with counters, MD5 and SHA-1
• Mandator- or campaign specific credentials for secure transmission
• Transmission metadata, i.e.: Count the number of successful transmissions and send the number of the last successful transmissions as a prefix to the next transmission.

Aspect 3: Flexibility in Business / Campaign Rules

MaMa needs to support several categories of campaign rules (sometimes called business rules)

• What are required and possible activities in this campaign?
• In what order shall these activities be executed?
• Certain types of activities (especially data import activities) are sometimes triggered by «Partner» organizations. What kind of event triggers what activities?
• How often to remind clients/customers by letter?
• When to call clients/customers by phone?
• What data is mandatory from the customer and what is optional?
• How long to keep data records, when to delete or archive data records?
• Whom to contact when certain (data) conditions arise?

Aspect 4: Flexibility in Data Export

Now that MaMa has received and processed data (by import, transmission and rule processing), it needs to send data to the campaign partners. Analogous to data import, these receiving partners have very specific requirements concerning data formats.

It is pretty common for MaMa to receive data from a partner company or mandator in CSV format, import it into its own relational database, process it record-by-record, export some records in XML to one partner and some other records in a fix format to another partner.

1.2.2 Quality Goals (Scenarios)

Prio 1: Flexibility

MaMa-CRM can:

• import and export (configurable) CSV and fix-record-length data.
• import and export data via ftp, sftp, http and https, as client and server.
• handle compressed data. Compression algorithm is configurable per activity, standard lossless have to be supported.
• handle encrypted data. Security credentials need to be exchanged between parties prior to campaigns during campaign setup. PGP or derivatives are recommended.
• handle hashes or similar transmission metadata, configurable per campaign.

For all these topics, InDAC administrators can fully configure all campaign-specific aspects within one workday.

Prio 2: Security

MaMa will keep all its client and campaign related data safe. It shall never be possible for campaign-external parties to access data or metadata.

InDAC Administrators need to sign nondisclosure contracts to be allowed to administer campaign data. This organizational issue is out-of-scope for MaMa.

Prio 3: Runtime Performance

MaMa can fully process 250.000 scanned return letters within 24 hours.

1.2.3 Non-Goals (Out of Scope)

• MaMa shall be exclusively operated by InDAC. It shall not evolve into a marketable product.
• MaMa shall not replace conventional CRM systems, like Siebel™, salesforce.com™ or others.
• MaMa does not handle billing and payment of any charges generated by its activities, e.g. sending letters or others. See section 1.1.3