Scenario - bxp and Person-centric design

1 Central Database Design

In designing a database infrastructure it is important to build a solution that is capable of handling the requirements of current implementations and also expandable to handle the requirements of planned / projected requirements.

With data protection and up to date record management now a vital part of every businesses central data management plan, solutions for legacy systems can present enormous challenge.

Take for instance a large central customer list which is loaded into a big CRM system. A sample of records are taken to allow a limited marketing campaign. There are loads of updates of data to make. A second campaign for a different product includes overlaps. How do you ensure no double calling of customers? How to updates from one campaign up date the central and other campaign. bxp facilitates management of all and central campaigns and includes a wrap around for central update of a big CRM system or data warehouse.

If as part of the first campaign, someone opts of out marketing messages, it is the company's responsibility to update all the other campaigns and programs not to contact that person again. Given the speed of change and potential volumes of users, bxp is ideally positioned to remove this challenge in real time.

2 Capability

bxp has a custom database infrastructure called a form. These forms are made up of a number of tables. The tables store data records and an audit trail to record touch points with those records. There are also three support tables which facilitate operational activity, database field mapping to allow for external sources update data and a field data definition table which records custom information about each field. Each of these campaigns are identified by a custom Id. Referring to these campaigns by Id allows for unique information reference.

• CDA = Campaign DAta (a data record)
• CCL = Campaign CaLling (a contact record which has interacted with the data record)
• COU = Campaign OUtcome (functional definition of activity to be engaged after contact with a record)
• CFN = Campaign Field Naming (naming of fields to allow for integration with external data sources)
• CDD = Campaign Data Definition (additional information about each CDA data field)

Traditional database design will see the functionality developed around a customer. The purpose of bxp as a sales and marketing tool will see people that are not customers and/or are former customers. This requires a different design approach.

3 Person-centric build approach

3.1 Generic Design

Considering a centralised record stored in a Person table is a structure to store information about customers and prospective customers alike.

• Primary details are used to identify the customer regardless the source of the information.
• Existing Customer Details allows the person record to be linked back to centralised company records such as those in existing systems.
• Marketing Permissions are centralised to provide a central repository for all campaigns as to the ability to contact a person.
• Marketing Information and Social Media provide further information to facilitate sales and cross sale background information to help the sales process.
• Security fields and GDPR compliance fields are added
• The Key Dates provide the validation and audit requirements for ensure proper contact is maintained regardless of the marketing campaign.
• Key Information provides the resources to be able to track the primary sales opportunities against customers and non-customers alike.

This schema would be an evolving developing schema where time and marketing activity will see it expand to facilitate better insight into the customers and potential customers. Further development of this concept allows for the following to be constructed.

3.2 Data Loading

If a company has been in existence for a while, then they will have amassed customer data and it is probably in various places. Operational systems, accounting systems, Excel spreadsheets and older systems.

1. The data is loaded with whatever data is available into the new person form.
2. The form is refined to make it usable for contact operations
3. A data cleaning exercise is performed to remove dud records e.g. no name, test records, etc.

3.3 Form Design

Forms allow for any data infrastructure to be built. A form can be built in isolation from the central Person record. Then when the form is designed and deemed usable for contact operations, a number of integration steps can be implemented and links can be established.

Using a worked example of a contact list derived from another database or source e.g. data warehouse.

1. The fields in the new form are aligned with the fields available in the Person database.
2. A further cleaning exercise is performed which allows information in the central Person database to filter into the form, especially regarding contact permissions.
3. A clean is done on the form removing all non-contactable records (i.e. data based removal, existing customers and customers where contact is not appropriate)
4. Depending on the age of the campaign data, a feed into the central person database can also be performed.
5. A two way comparison of fields is performed to update the form and the central person records to see if extra information is required in the person database or could be captured during the performing of the campaign. (This steps ensures an evolving and growing Person database) Live link systems enable using AJAX in the form will allow a record to display person information and facilitate further linking and central updating.
6. Where extra information such name, contact detail and key date information is to be updated, this can be done in real time.
7. The ability to add link information linking a one person record as a child / relation to another person record will increase the value of the person stored information. This also allows for ever increasing information gathering on the person.

This process can be applied to any batch loading / availability of information. It does also allow a form to be built and operated in complete isolation of the person database thus ensuring the quick turn around and flexibility of campaign where required. A campaign template can be developed with these primary links in it which would enable a copy process to speed up new campaign integration.

3.4 External Systems Integration

Not all data transfers will be in batch. Where real time communication is required, such as feedback from a public website system, the bxp API can facilitate external systems pushing information into bxp forms. The records though pushed in in real time can be treated the same as batch data but with the cleaning and lookup processes being performed on a record by record basis rather than a batch processing basis. With a generic processing engine available this will ensure all forms can be quickly set up and consistent across all campaigns.

In the diagram, a public website, can push information into the purple form database. This form database is linked in turn to the Person database. This abstraction provides maximum flexibility and yet still keeps central auditing capability.

3.5 Centralised Record Update Capabilities

With a central repository of existing customers all marketing campaigns will be required to keep this repository up to date. This could cause an excess of update management and systems communications issues. By centralising all updates from the Person table systems such as a data warehouse can be updated from the central person record which has been fed by all marketing campaigns.

4 Project Outline Steps

4.1 System Implementation Notes

4.1.1 System Requirements Analysis

• The original project requirements
• Previous execution plans

4.1.2 Feasibility study

The project plan

• Return On Investment analysis

4.1.3 Systems Analysis and Design

Notes on the code development

• Project plan with date / times
• bxp API integration
• Database schema
• bxp application

4.1.4 Code Generation

Notes on the systems and integrations development

• Form JavaScript
• AJAX Links to Person
  • Reading person data Java_Script_Live_Search_Table
  • Writing person date JavaScript_Data_Injection_Campaigns
• MetaData Program to clean on Loading of data
• MetaData Program on outcome

4.1.5 Testing

• User Interface Testing
• Data transfer tests
• Data loading test

4.1.6 Maintenance

• On-going data protection operations
• Managing data contact lists and outbound contacts
• System refinement and evolution

4.1.7 Implementation

• Roll out requirements
• Training and operational understanding
• Implementation review sessions