@ LeadCrunch.ai
LeadCrunch.ai is a marketing technology startup that uses AI to facilitate more effective marketing strategies. To track and fulfill orders, a complex human business evolved over time. I developed an information architecture to rationalize this process and integrate it into our client facing product.
As LeadCrunch’s revenue grew, a manual business process was reactively developed to keep up with demand. This process involved many people and tracking tools across lots of departments to approve and run each order. This was a decent stop gap solution, but ultimately it created challenges for the sustainability of the business. Initial attempts to map out the process only revealed its unwieldy complexity.
This complexity had direct consequences for the performance of the business. It delayed order fulfillment and impeded the development of a consistent customer experience in the product. It was also extremely fragile – the interdependencies throughout the process made it expensive and difficult to iterate. Although clients often asked for access to more detailed and up to date information about their orders, there was no clear way to integrate the backend approval process into the product experience. When LeadCrunch moved to offer a self-service version of its product, it became necessary to find a clean way to organize and integrate this backend process with the product.
The first step to re-designing the order approval and fulfillment service process was to create a detailed picture of the steps and systems involved. We needed to model the nuanced details of the end to end process. To do this, I teamed up with a product manager to create a service blueprint representing the end to end lifecycle of each marketing program.
Over the course of two weeks, we conducted in depth interviews and user observations with all of the teams involved. During this process we built a model of their workflows and how orders were passed between them. The result was a detailed service blueprint identifying all of the discrete steps taken to launch and fulfill each order. In total there were 108 critical business processes that needed to be organized and connected to the product.
Once we had collected an organized picture of the order process, I worked with stakeholders, engineers and other designers to re-organize the information into something we could work with. Our goal was to develop a modular domain model that could be used to rationalize the business process so that it could be deeply integrated into the product.
The system we developed to solve this problem was an information architecture that we called the “Program Lifecycle.” This design grouped sets of business processes into discrete “Program Stages” – well defined modular units that shared a single data model. Rather than trying to integrate with a host of ever changing manual processes, this allowed us to describe the order as moving through a network of interconnected stages. Each stage contained logic about what message to show users on their program details page, what actions and next steps needed to be shown, as well as the business logic concerning interconnections with other stages.
This provided a structure for organizing the business process within the product. Although the specific triggers that move the order from one stage to the next might change, with this framework it became clear how to adjust the product to accommodate the new workflow.
Once we had developed this model of the program status information architecture, I organized a workshop with the department stakeholders to define the MVP version of this experience. In this session we reviewed the service blueprint and then applied the program stage framework. We were able to identify the minimal number of stages needed to organize our core business process within the product. This MVP integrated our service process neatly into the product experience while minimizing changes to existing workflows.
The careful work and analysis to produce this business process architecture paid off. We created a clearer and more consistent experience for users as they placed orders. The product could now reliably show users exactly what state their order was in and what steps were needed to advance it to the next stage. Users were left with a deeper sense of control over their orders. The information architecture also created a clear roadmap for LeadCrunch to move more of our business logic into the product incrementally over time, extracting expensive third party data tracking tools from our core business process.