ECW
CRM
Designing an Operational CRM for 46K+ Active subscriptions
I designed the product from the ground up, translating partial business requirements into a CRM connecting vehicle recognition, subscriptions, payments, retail activity, customer service, and branch operations.
Evolved through multiple design phases over 6 years · Supporting 31 active branches
context
Express City Wash needed a CRM tailored to a vehicle-based subscription business and connected to its existing license plate recognition system. Off-the-shelf solutions were too rigid to support the company's operational model and future growth.
With a limited initial budget, I had five days to translate partial requirements into a prototype, working directly with the CEO, Customer Service, and CTO. The goal was to demonstrate the value of a custom-built system and secure the client's investment in its continued development.
After the project was approved, the platform was developed and expanded. I returned to it across multiple design phases over the following six years, adding new capabilities as the company's operational needs evolved.
The challenge
A standard CRM could not support a vehicle-first business
Express City Wash did not operate around customer records alone. Each visit began when an existing camera identified a vehicle at the branch, and the system then needed to connect that vehicle with its customer, subscription, payments, purchases, wash history, and service activity.
Off-the-shelf CRM products were built around conventional customer management and could not support this connection between digital records and physical branch operations. The challenge was to define a custom product structure that reflected how the business actually worked, while remaining flexible enough to accommodate new services, account types, and operational workflows over time.
A vehicle-first model connected each wash to the customer, subscription, and branch workflow.
The solution
Operational Platform Connecting Vehicles, Customers, and Branch Activity
I designed a custom CRM around the vehicle as the central operational entity. The platform connected each vehicle to its customer, subscription, payments, purchases, wash history, and branch activity, while giving Customer Service and branch teams a shared view of the business. Over time, the product expanded to support company accounts, retail operations, loyalty programs, external integrations, and new workflows without replacing its original foundation.
PRODUCT DECISION 01
When a Cleaner Interface Created More Work
INITIAL RATIONALE
Invoices contained a large amount of information, so I placed them on separate pages rather than opening them inside the customer profile. My intention was to keep the profile focused, reduce visual density, and give each invoice enough space.
WHT I HAD OVERLOOKED
For Customer Service, reviewing an invoice was not an occasional task. It was an action repeated dozens of times throughout the day. A user questioned why they had to leave the customer profile and load another page each time. Although the flow added only one navigation step, it repeatedly removed them from the context in which they were working. The issue was not the number of clicks alone. It was the interruption created every time the user moved away from the customer record
DECISION
Keep Frequent Actions Within the Customer Context
I replaced the separate invoice pages with modal views inside the customer profile. This allowed users to inspect invoice details and then return immediately to the same customer record, without navigating between pages. I gave up the additional space and visual separation of the original design in order to support the way Customer Service actually used the system. What changed in my approach The feedback exposed a gap between an interface that appeared cleaner in isolation and one that worked better across a repetitive operational workflow.
MY ROLE
I defined the original invoice flow, gathered direct feedback from a Customer Service user, reconsidered the interaction model, and redesigned the experience within the customer profile.
OUTCOME
Invoices could be reviewed without leaving the customer record, preserving the user's working context during a frequently repeated task.
PRODUCT DECISION 02
When the Account Structure Blocked Legitimate Customer Use
Initial approach
Company employees were handled as a separate customer type in the system.
Their company vehicle subscription was tied to that customer structure, while phone number, email, and vehicle number were used to prevent duplicate records. What the structure overlooked The same person could also need to act as a private customer. Because their identity already existed as a company customer, they could not add a personal payment method, purchase products through the app, or add another vehicle with a different subscription type. The system treated the company relationship as part of the customer's identity, even though it was only one type of subscription connected to one vehicle.
DECISION
Separate the Customer from the Subscription Type
Together with the client and CTO, we revised the model so that the customer remained the permanent entity. A customer could hold multiple vehicles, with each vehicle representing its own subscription, including private, company, or work-related subscription types.
Personal purchases and payment details remained under the customer account rather than under a specific subscription.
What changed in the product
When an employee left a company, only the company subscription was removed.
The customer account, personal purchases, payment details, and any additional vehicles remained available.
MY ROLE
I worked with the client and CTO to understand the limitations of the existing structure and translate the revised model into the required flows, states, and interface behavior across the CRM and customer app.
OUTCOME
Customers with a company subscription could also use the service privately through the same account, without creating a second identity or losing their personal activity when the company relationship ended.
OUTCOME
From Prototype to Operational Infrastructure
The initial prototype became the foundation for a CRM that evolved over six years to support customers, vehicles, subscriptions, purchases, and branch operations.
6 years in active use, 31 active branches, with 2 more preparing to open
46K+ active subscriptions.
REFLECTION
What I took from this project
This project taught me that operational products cannot be designed around visual simplicity alone. A cleaner interface can create more friction when it ignores task frequency, working context, or the structure behind the screen.
It also reinforced that my role is not always to originate the system-level solution. Sometimes the most valuable design work is listening closely, identifying where the existing model breaks, and translating a collaborative solution into clear, usable product behavior.