TerriTool App Case Study (Patent-Pending)
TerriTool is a route optimisation tool for territory sales teams that was initially built for EDI express in an effort to automate the 20 – 30 hour excruciating route creation task each salesmen had to do every month for their monthly accounts. This solution quickly evolved in to a product called ‘TerriTool’ that is currently being sold to territory sales teams as a solution to reduce the amount of time spent creating territory based routes and also manage their day-day sales activities within the product.
Salesmen of EDI express would spend around 20 -30 hours per month creating an optimised route for visiting accounts/leads, the manual process consisted of:
- Manually pining each account on a physical map
- Circling clusters (based on visual feedback)
- Drawing a line between each account/lead on the map for what the salesmen would image be an optimised route.
- From this, the salesmen of EDI Express would manually create an excel list of the accounts/leads in the order that they visualised would be efficient.
EDI express salesmen would typically process around 400 – 600 accounts per month. This was the reason it had to be manually done as platforms available could not process routes above 50 waypoints. Google had a limit for 10, TomTom had a limit for 40, Here Maps had a limit for 50, and Garmin had a limit for 50 as well.
EDI Express was also using SalesForce as their CRM and could not get the best use out of it as it wasn’t designed for field salesmen. More importantly, each salesmen had to spend extra time updating the SalesForce CRM, which was affecting productivity.
We always do this because we want to ensure:
- ‘Back-forth’ during the system development phase is minimal
- Expectations for the system are extremely clear for all parties involved.
- The right technological solution is proposed for the development of the system.
- Reliability of the technological solution is heightened.
- Development delays are minimised or avoided.
The solution assessment is designed to work as the foundation for a successful development of the system and it has helped us ensure a 100% success rate with every system we’ve built.
Due to the complexity and size of the expectations, we performed the solution assessment twice. Firstly for the CRM App and second for the Route Generation System (AI).
For the CRM App we completed the following:
- Define User Personas
These are descriptions of the type of the users that expected to use the app. It helps with aligning the user experience of the app with the intended audience.
- Define User Flows
User flows are a visual representation of the expected user’s journey on the mobile app. This means we plan how the user will use the app from screen-screen. This helps with ensuring that the user experience of the app is in alignment with the intended audience and that the objective of using the app is easily achieved.
- Design Wireframes & Prototype
Wireframes is a mockup of each screen of the app in Black & White form. All the information from the User Personas and User Flows are used to design the wireframes. The wireframes and user flows are merged together to create a ‘clickable-prototype’. Once we got to this stage, we tested, refined, prototyped, tested, refined, prototyped, tested, refined… until we reached maturity of user experience and app expectations.
- Assessment Of Required Integrations
We assessed all the integrations EDI express expected for the system, these included: SalesForce (2 Way – via API), EDI Express (via RPA), and Google Sheets. The objective of this phase is to ensure that the integration is correctly mapped out and the identification of risks with the integration is carried out to ensure development is not delayed and a reliable solution is built.
- Project Plan Creation
We created a project plan that includes, an accurate cost of developing this system, milestones within the project, projected timeline, solution architecture clearly defined with technologies involved, risks clearly defined with risk mitigation plans.
For the Route Generation System (AI) we completed the following:
- Determine the definition of clusters/groups.
- Determine the algorithm that the should dictate order in which the clusters/groups should be.
- Determine the algorithm that would dictate the ‘Start’ and ‘End’ point for each cluster/group within the route.
- Define the expectations of self-learning that will be used to enhance the systems ability to determine clusters/groups based on multiple parameters.
- Define the expectations of self-learning to enhance the systems ability to determine the best order in which clusters/groups should be.
- Define the expectations of self-learning to enhance the systems ability to determine the best ‘Start’ and ‘End’ point for each cluster/group within the route.
- Understand the parameters that can we utilised for the system
- Determine other systems that will be used and assess how they will they work together to achieve the Route Generation system.
- Create small samples with limited AI to act as a prototype to ensure EDI Express is investing in something fruitful.
EDI Express and the team were incredibly satisfied with the solution assessments and extremely grateful to have something tangible to work with before the development of the actual system. With eager excitement, EDI Express had advised to move on to the next stage.
The route generation system was built with the ability to create 2 type of routes.
Route Type 1 = Simple Route, which is able to achieve optimised routes of 500-1,000 waypoints (accounts/leads) generated within 5-10 minutes.
Route Type 2 = Smart Cluster route, which is able to achieve routes of 500-5,000 waypoints (accounts/leads with a bias towards clusters, keeping salesmen within a certain area before moving on to the next. This type of route would generate within 10-30 minutes due to the magnitude of computational power needed to process it.
Our solution for the EDI Express turned a 20-30 hour task into a 5-10 minute task while producing a much more optimised clustered route (due to the consideration of more parameters) when compared to the manual process the sales team at EDI Express would follow. This meant that the EDI Express team could spend more time and make the most of their time on the field making sales with a route more tailored to their workflow and spend less time on non-revenue generating tasks.
Shortly after the completion of this project, the system was rolled out to other companies as a product and has 2,000 active customers (18/10/2019). The software is sold as ‘TerriTool’ using the SAAS business model and we’re still working with TerriTool. (Developing, Imprivnig, maintaining, supporting)
In addition to this we developed a mobile app and web app that allowed field salesmen to easily update the CRM as they work, and most importantly help them become more productive while on the field. The capabilities of the app allowed field salesmen to quickly search up account details, edit routes, create new routes and completely function from the device itself.
To everyones surprise, a 2-Way Sync was also created with SalesForce so that all the data being entered into TerriTool by salesmen was sent straight back to SalesForce so that other areas of the business were not affected.
Develop for success
As soon as the TerriTool system was successfully rolled out with EDI Express and converted into a product, TerriTool and PICWA established a long-term relationship where we supported the app and also worked closely with the TerriTool team to continuously improve the system.
We had to perform a ‘Develop for success’ something thing iisnisn, which is our first step before entering a long-term relationship.
In this we build out
- Error recognition systems for all exceptions of every component. (Ensure we see errors before users do and also help us debug issues that arise)
- Analytics systems for for every component of the system. (Ensure we have data to support issues that occur and help with server management & planning).
- Implement session tracking for every component of the system. (This helps incredibly with the debugging as we’re able to see how certain issues happen or make the system crash).
- Implement notification systems for downtime in all components of the system. (Ensures we know the system is down before anyone else does)
- Determine contingency plans for error scenarios, downtime scenarios and user-inability scenarios. (Ensures that all stakeholders understand how to respond in these scenarios).
- Ensure that software improvement plans are in place. (Ensures that the system becomes stable, mature and improves).
- Develop basic automated testing systems and also plan the development of further automated testing. (Helps with speeding up the development cycle, helps with deploying hot fixes quickly, and helps increase reliance of future deployments).
Support & Continuous Improvement
Once we did this for TerriTool, we were all set to go live with a larger pool of customers and this made sure that downtime during critical failures was minimal, development of improvements were within quoted time and the system stability had continued to increase.
TerriTool has 2,000 customers as of (18/10/2019) and is growing it’s customer base with peace of mind, knowing that they’ve got a development team they can trust and help them grow.