Generate custom lead notifications using generic email template and lead meta information
In the world of ecommerce, lead management is one of the core marketing areas which if done effectively, translates to high business value. Prospective buyers visit ecommerce portals and at times show up their interest in any product by filling in inquiry forms. To follow-up on that lead, sellers/dealers need to be notified of the prospective lead with all lead relevant details ideally in real-time through notification channels like emails etc. This requires an ecommerce portal to provide inquiry forms and a portal to send notification to business, of that prospective lead.
Since there can be major sales events round the year which a business wishes to capitalize on hence they need the provision of adding new forms or customization of existing ones. Also since information captured on customized forms or newly added forms can vary considerably hence platforms need to provide a way to capture those updated information. Customization of forms, adding new forms and creating notification tailored as per customization takes time. This customization may also require change to the existing platform code base. The problem is compounded further if there is a third party involved in mass notification (like email service providers). For every change, the third party provider also needs to be coordinated to provide for updated templates that capture customized information.
In this document we attempt to provide a solution to speedup the entire process of authoring new forms/changing existing ones followed by real time changes to email notifications (that are in sync with form changes) and that too without code changes.In our experience on the platform that we are going to discuss (in the subsequent sections) we found that new authoring and notification architecture reduced deployment cycle time for any change from weeks to minutes.
Lead notification current architecture
Below is the current lead notification architecture of the ecommerce platform under discussion (Fig 1). This ecommerce platform provides marketplace, custom-branded catalog/inventory websites along with lead management portal to various sellers. The lead management portal (LMP) works as a CRM where sellers can manage the state of their leads. Each seller can have a custom WordPress site that is integrated with the LMP.
Currently WordPress’s Custom-Form-7 plugin is used to create standard lead generation forms on these websites. A visitor can browse these sites and fill those forms for an inquiry. Data filled in these forms on submission is sent to the LMP through an API. Each form on LMP is linked with a dedicated email template specific to that form. The lead data that is filled in by the end user and sent over the API is mapped to the email template and thus sent through email notification to the seller. Fields used in these forms need to be mapped to LMP to be used in notification templates. Hence if any forms are modified to use a field that is not mapped to LMP then that field cannot be used in any email template unless changes are made to LMP and email templates.
Current architecture’s – problem & requirements
The website’s architecture is built in a way that each seller has a few specific predefined lead generation forms on their site. Whenever a visitor fills out a form, their data is stored within the seller’s lead management portal and an email is triggered to the seller’s team member with the lead’s details.
Each seller deals with multiple types of catalogs and categories. Platform often gets requests from these sellers to have custom fields added to their predefined set of forms or to define a new form based on some specific events like offer/sale.
Each predefined form is linked with an email template provided by a third-party Email marketing service provider. If existing forms are modified by adding/updating fields or a new form is added then such changes are not part of LMP and predefined email template. To support any customization either a new template needs to be created or existing ones need to be updated. Also LMP code needs to be updated to support such changes else sellers will receive email without displaying customized information.
Since any customizations require modification to email templates and LMP code, hence it usually takes a few days or even weeks in order to incorporate such requests. This may mean difficulty in achieving such customizations around important seller events and hence possible loss of business value to them.
Proposed lead notification architecture
We proposed to provide modified architecture for seamless customization. This is achieved through a series of steps
- Incorporating drag-n-drop based form builder
This form builder is a plugin that extends the custom-form-7 plugin. It has the following capabilities.
Design surface for flexible authoring of forms.
Form builder provides a UI to generate a standardized and consistent HTML based form layout (used later) as compared to non standardized HTML layout used in current architecture.
Non standardized HTML layout (current architecture)
Drag-n-Drop Builder layout (proposed architecture)
Standardized HTML layout – using form builder (proposed architecture)
Inline editing/deletion of form fields on design surface
One can easily drag-drop, position, shuffle, edit/delete and map form fields for any form using form builder UI
- Field Mapper
All the existing predefined forms are converted to support form builder. Thus one can seamlessly customize even existing forms through drag-n-drop surface. Every field in any form needs to be mapped to some LMP field. Thus all LMP fields that can be mapped across forms are made available via field mapper. If a form field cannot be mapped to any LMP field then it can be mapped to a custom-data field. Every field on the form can be mapped to one and only one LMP field with the exception that custom-data field type can be mapped multiple times with different fields
As shown in the above image, the company name field is mapped to the company-name field which is an LMP field. “Hear-about” and “interests” fields are mapped to custom-data.
- Lead data fields segregation/classification
For better utilization of LMP fields on email templates, all LMP fields are
segregated into four field types:
Contact info: All the contact-related info of the lead such as phone, name, and email id.
Additional info: Fields such as comments, additional requests, birthday info, and questions.
Catalog info: Product-related info, Manufacturer, category etc.
Enrichment Data: (Visitor’s behavioral and activity data.)
- Form fields meta-information generation
Whenever a form is authored using form-builder it generates a standard HTML layout of form (as described before) that is saved in the WordPress database. On every change/save to form’s html layout, it is parsed to generate an XML document that defines form’s fields meta information which is synched and stored in real time via an api on the LMP portal. Below is the structure of the generated XML
As shown above figure the XML structure hold details of each field as below-
- data_field – field name as defined in LMP database schema.
- data_source – lead source (source of lead like lead form)
- tag – tag as defined by form builder for every field [for future use]
- label – Label of the field on forms and email notification (eg. Company Name -)
- mapped_field – LMP standard fields (eg. first-name, phone, custom-data)
- data_type – field type (eg. text, textarea,number,tel) (server side validation)
- field_type – field type based on classification (as defined in section 3)
- Is_required – field required or not (server side validation)
- Field_position – position at which field to be displayed on the email notification.
- Creation of generic email templates
As discussed earlier, previously there was a separately defined hardcoded email template for each form as shown below
Lead form specific email template
It was difficult to customize the above template. All the label names (like Name, Phone, PostalZip etc.), their positions and number of fields on these templates were predefined and tailored for a given form. To change any of this would require modification to the existing template or creation of a new template.
To overcome these limitations a generic email template was created as shown below
Generic Email Template
From the above template one can see that there are separate generic sections for each class of fields like contact information, additional info, catalog/product information.
For example CONTACT_INFO_1, 2, 3,4 ,…10 tags are predefined as part of the generic template. One can choose any number of contact information tags ( max 10 in number for fields like name, email, phone etc.) for a form and in any order with any label name to assign relevant contact information to be displayed in the email template. There are similar place holders for additional and catalog info that can be used for any email notification.
XML structure generated for any form (which is saved in LMP), is used to create email tags defined in the generic template.
For example, %%CONTACT_INFO_1%% is generated as follows: from generated XML, <field> tag that has field_type value as contact-info and field_position as 1 is taken. This defines the section as well as the position of that information in that section. “label” tag from that field node along with value entered by the end user is used as:
%%CONTACT_INFO_1%% will be replaced by <label>:<user entered value> in section contact-info at position 1
Following diagrams illustrates new architecture around generic templates
Generation of XML meta information from form’s HTML layout
Email notification using generic template and XML meta information
Benefits of the new architecture
- Using this approach, a Seller can see consistent lead details across lead form, LMP, and email templates.
- Instead of using dedicated templates for each form and creating a unique template as per the requirement of a seller, generic email template can now be used across sellers and for all forms thus removing the need to create a new template each time customization is required.
- Since the generic template is flexible enough to support any number of fields in any order with any labels, hence the same can now be used for all new forms across sellers giving them freedom to have new forms which can also work flawlessly with LMP providing them real dynamic lead notifications experience
- It will reduce the turnaround time of customization and new form authoring from days/weeks to minutes. The moment any changes are made, it is replicated in real-time for lead generation.
- New architecture solutions around WordPress and LMP provided for a high degree of automation removing needs of making code-level changes to a minimum.