PLATFORM FOR LOCALIZED EMARKETING
Situation: A client wants to offer email and social marketing services to their auto dealership customers.
The client provides technical and marketing services to thousands of auto dealerships. They want to offer email and Facebook marketing to their customers, and manage the program with a small team in their headquarters.
The response - Create a Local eMarketing platform
After two-weeks of rapid whiteboarding and quick coding, a fully functional test version was ready to implement with 15 test dealerships. The client's new eMarketing team uses a web application to enter dealership information, the specifications of the desired target audience, and the creative elements for the email and Facebook ads. That teamcalso determines the desired schedule and enters that in the web app.
A new API is built on AcquireWeb's data warehouse that will provide list counts based on target specifications (demographics, car ownership, and radius around dealership). Once a target definition is selected, this api also will generate the list and make it available for deployment.
We created a new API that our client uses to send data from the POS systems at the test dealerships, with the names and addresses of customers. This will be matched to the marketed list and a control list, in order to calculate lift and program ROI.
In the initial test phase the actual deployment of the campaigns is done manually.
Test successfull, the platform was expanded to hundreds of dealers and other clients
During expansion, much quicker than planned due to customer excitement, the deployments were fully automated and the web interface much expanded with reports and other tools to aid the user. Several issues required quick action:
Rapid scale-up created issues within our client's organization. We added many new reports and other project management tools in the app designed to help our client's staff manage their workload.
The scale of the email deployments created issues in deliverability. A new process was created to allow scheduling rules to be automatically applied at the time of deployment.
Distribution of report to hundreds of dealerships became overwhelming. New systems generated PDF reports and distributed them to a dealer-specific list each week.
What was Jay Dean's role?
As Chief Architect, Jay's intial role was to design an aggregate group of systems that would satisfy the request, and then to develop the tech requirements & user stories. Under the tight timetable, no developers were available for the application web interface and database backend, so Jay stepped in to create those in the initial test version.
As the product expanded and was adapted to other clients, Jay worked directly with the users to develop new application elements that solved their critical needs. He continued to act as Product Owner until the merger with Claritas.
For the API calls to the email servers Jay adapted work created for the company's internal use to this new product, and added the new automated scheduler element.
Our client has an internal software team developing their own tools, and the agreement between the two firms defined what elements were AcquireWeb's responsibility. However, the growth of the program overwhelmed thier staff and systems. Though this what "not our job", it was a risk to the success of the program. We were able to step in and add elements to our application intended to fill gaps in their organization. Sometimes, one needs to look past the formal allocation of responsibilities. When there is a barrier to success, anyone with a solution needs to step in.
Success breeds excitement, and we were unable to hold to the a "slow and careful" roll-out plan. Also, manual execution by our services team got us into the test rapidly, but beame a barrier to growth. Understanding the need to fully automate every step is key if you hope to scale quickly, and human intervention must be minimized to remain profitable.