The Dealer Management System, or DMS, I worked for empowered dealers to keep track of their inventory, sales, paperwork, and much more. One of the things it is not able to do is handle Customer Relations throughout the entire deal. While the system can save prospective customers interested in a specific vehicle and can track customers after they have made a purchase, it cannot handle customers who have expressed a general interest in a variety of vehicles nor provide a quick way to contact them via phone or email. The only way to store this data is via the sales screen, which requires detailed information to even save (not useful for a quick prospect who walks onto the lot).
As such, we have always had to suggest our customers seek another piece of software, a dedicated CRM (Customer Relation Management). This was a poor solution to the problem because of two reasons. First, we are making our customers have to use another piece of software instead of their DMS being able to handle it. Second, those who do go out and use a CRM want to be able to have that data transfer over into the DMS so they do not have to reenter data.
We decided to approach this problem from two fronts. We would develop a way to import customers from CRM programs so customers did not have to do double entry. While we did that, we would also develop a “Simple CRM” to be a part of the software. While not as robust as a software dedicated to CRM, it would provide a base set of features for customers who are unwilling to adopt a second program but still need a better solution for handling prospective customers than Frazer allows for.
So the ultimate question was, what does a simple CRM need to have?
To answer this question we immediately reviewed our customer feedback/suggestion portal. We sorted all of the content that related to CRM features and then made a list of those customers. We conducted phone interviews and found out information such as if they currently use a CRM program (as well as why or why not), what they would expect of a CRM, and what it means for their business. This provided us with a lot of very detailed information and allowed us to get a feel for our type of customer who would utilize this feature.
While this research was being done, we also did a competitive analysis of the various CRMs available for automotive dealers. Some of these were companies that were looking to integrate with us, and others were competitors that had their own DMS and offered a CRM as an add-on product. We scanned through the feedback/suggestion portal help us identify four CRMs to evaluate. We then also compared it against a list of features our users stated they needed, as well as a list of features our demo dealership says they need as well.
With the list of features in hand we then moved to developing some sketches to have an idea of what these features would look like in the program. As with past projects this provided us with a unique challenge because the software itself has a bit of a dated look, however we were presented with the opportunity to create an entirely new screen instead of editing an existing one. Sketches were designed using our traditional look, and a more modern look. When the two options were presented to garner feedback, the modern look was preferred by all. We then moved forward with developing wireframes for it.
This project is currently on-going. The wireframes were shared with the developers and the owner of the company, however we hit a bit of a snag as several in the room had differing ideas of what “simple” meant. The potential lead programming on the project wants to approach the project from the direction of the integrations. Pulling the information from other CRMs and determining what fields we need to fill to accommodate them, whereas our recommendation was to put our system in place and have them send us the data we request. There was debate on whether a two-way integration was necessary or if a simple one-way into the software was sufficient.
Really we have hit an issue of how far do we want to go for our users. The original intent in the design was allowing them a way to enter their leads into their system, whereas it was proposed in the developer meeting that we allow them to pull in leads for web and other sources, which complicates the process.
The project is currently in the hands of the developers as they determine how far they want to take this project (meeting vs. exceeding customer needs), who will be the lead on it, and how it falls into place with our CRM integrations.
Is “Simple” really that simple?- We were able to determine the bare basics that our customers would need in a CRM, but we were unable to answer “why stop there?” We agreed that more robust features that competitors offer were outside the scope of this project and users should rely on other software for such things, but there were features we could implement. This would mean more effort, time, and costs would be associated with it. So while we addressed the problem by answering the question, our answer generated more questions.
Isolation is not the best policy- The company as a whole has never relied on competitive analysis. They have always had a policy of “we just do our thing” as opposed to conduct research on competitors and their features. With the research done on the mobile app we got a peek at what researching competitors' products could provide for insight into our own projects. For the first time the directive to actually conduct competitive analysis was given, and it helped show that it is an important step. It helped us answer our question as to what to offer in a simple CRM. It is likely to now become a standard step in projects.
Change is good- Maintaining our existing layout in new screens limits us. While it does “maintain the look and feel”, the way we present data is not optimized and can become inefficient. Opening our designs up to new styles allows us to showcase how updated features can improve the user’s workflow and interactions with the program. This bypasses the worry the company has about changing existing screens, and provides us an avenue of easing users into it whenever we create an entirely new screen/feature in the program.