PLATFORM FOR LOCALIZED EMARKETING
Situation: A client wants to add email and social marketing services to their offering.
The client firm provides information technology and marketing services to thousands of auto dealerships. They want to offer email and social network 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 platform was ready to implement with 15 test dealerships. The client's new eMarketing team used 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 team also inputs the desired schedule. The same web app tracks program status and progress, and reports on results.
A new API, built on AcquireWeb's data warehouse, provides list counts based on target audience specifications (demographics, car ownership, and radius around dealership). Once a target definition is selected, this API generates the mailing list and posts it to the mailing servers for deployment.
A second new API receives sales data direct from the POS systems at the dealerships. When matched to the marketed list and control list, the system calculates sales lift and program ROI.
In the initial test phase the actual deployment of the campaigns is done manually.
Test successful, the platform was expanded to hundreds of dealers and to clients in other industries
After program 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 streesed our client's organization. We added new reports and other project management tools to the app, to help our client's staff manage the workload.
The scale of email deployments created issues in deliverability. A new process allowed 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 initial role was to design an aggregate group of systems that would satisfy the request, then 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.
Jay authored all the internal and external documentation for this product, including the two APIs.
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 their staff and systems. Though this was "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.