Hello and welcome to the first of a 3 part mini series on our new CRM (Customer Relationship Management) platform.
Within this series we’ll breakdown the business requirements, technical decisions and the challenges and advantages of building and maintaining your own system. With Applikation being a software development agency there are some obvious advantages we have to achieving this goal, mainly our talented team of developers. However, being a software development agency has its own challenges which we believe are universal to the service industry. This series will explain the processes used by the Applikation team to formulate, design and develop a system from scratch.
To contextualise the challenge ahead, we need to start with our business needs. At the end of March, the pricing structure of the platform Directus.io changed. We used this platform to house our business and client data that allowed us to visualise our marketing funnel from lead to conversion to aftercare. We saw the platform as being no longer viable and it required a new solution.
So, our team reviewed off-the-shelf CRM platforms that are currently on the market including: HubSpot, Pipedrive, Salesforce and Zoho. They had some great features and they would work as a temporary solution, but they had a bloated list of features we weren’t interested in using and they didn’t provide the in-depth data we’d need. We required a solution that tracked a new client from the first intro call to project start date, whilst providing us analytics on key milestones throughout its journey.
We therefore made the business decision to build and maintain our own internal platform, as it’s not only what we do for our clients, but the requirements from our board of directors were that they wanted a platform that could visualise metrics that we can’t view on an off-the-shelf CRM. Our team needed a “finger on the pulse” platform that could allow us to view the vitals of our business. With 3 key initiatives as a starting point:
Marketing Analysis
Our first initiative was to make the marketing revenue more transparent based on the intro date of a client. Can we view and compare our marketing campaigns to spot patterns within an annual cycle? We needed to compare campaigns against each other, as well as comparing campaigns against how they performed previously. It was essential that this could be viewed quickly and reported on.We needed to have visuals on our current “Lead ConversionTime”. This was a metric we had little information, the requirement was to answer the following questions:
- How long do we take to convert a client from intro call to start date?
- Do different campaigns have different conversion times?
Client Management
We needed a platform that our management team could connect existing and future clients to marketing campaigns and track their progress. The platform must allow users to log new clients and assign them to the campaign they came from. This would allow us, once a project started, to track the revenue generated from that campaign. One of the hardest marketing challenges we face is knowing how to report on a client that was introduced 6 months ago, but has only now started a project. As from a cashflow perspective the current month is when revenue started, however from a marketing perspective that client should be allocated to marketing done 6 months ago. These were some of the challenges we needed to overcome.
ROI Analysis
Marketing companies provide ROI information, but only on the leads they generate (not the revenue that was generated from that lead). In the service industry this can be hard to calculate and is mostly retrospective. Leads can have wildly different project sizes and they could also have multiple projects they need quotes for that they may not plan to start immediately. It’s crucial to be able to analyse a campaigns performance based on the revenue it actually generated rather than the leads provided. After all, what good is a lead if it doesn’t convert?
Specification & Requirements
The above initiatives were the starting point of our development roadmap. We started to lay the foundations to build an internally accessible system that can be simply maintained by our internal development team. A platform that can provide the insights highlighted above, as well as, being updatable day-to-day by our management team. So, we needed a web app that can be accessed on any browser and fixing changes can be deployed effortlessly.
Our turnaround time for this project was 1 month. We needed to have the MVP designed, developed and deployed for our team to use within a month. This was deemed business critical as we needed to be able to input new clients and data as soon as possible to ensure we didn’t fall behind on any client requests. We’d focus on functionality and data visualisation as the highest priority for desktop browser use only. Our use case was day-to-day client management from a laptop, so device responsiveness wasn’t a priority, but a post MVP consideration. Our next step was to take these requirements and build a development plan and roadmap, taking into consideration the tech stack required to achieve the platform in the most efficient way. In order to do this we produced a feature list.
Features
- User Authentication – we require login, but not sign up functionality as the users would be added manually. The web app pages needed to be authentication secured as the data they contained were business sensitive.
- Insights & Daily Vitals Dashboard – a “finger on the pulse” dashboard powered by the data entered in other areas of the platform.
- Marketing Company & Campaign Setup – Add, remove and edit marketing companies and campaigns used by Applikation.
- Clients, Projects & Jobs Setup – Add, remove and edit clients, projects and jobs handled by Applikation. We decided early on that this was the best way for us to get the granular detail we needed for the Insights & Vitals Dashboard to function as per our requirements.
The above were the agreed upon features for our MVP. Now, what were we going to use to build this beast? What database should we use to build out the data layer quickly? What coding language would we use? Where would we host the repo and web app? These are all questions that will be answered in the next part of the series! See you there.
