I got a quick overview of TOA Technologies recently. TOA Technologies was founded about 5 years ago to solve “the cable guy” problem – customers waiting at home for hours without knowing when the cable guy, or any other appointment, is going to arrive. Their core idea was that they would predict, with a high degree of accuracy, when the person will actually arrive while engaging the customer in the process, keeping them in the loop. They aimed to reduce customer pain by giving them more information, more regularly updated information and more accurate scheduling. They found that they also needed to understand in real time, what people were doing in the field and how long everything was taking. They needed therefore to collect this information and to develop a predictive engine that would use this information to predict how long activities will take to better schedule, route and allocate staff.
What they have is a SaaS platform designed for all the stakeholders in the scheduling problem – technicians in the field and other mobile employees, call center staff, customers etc. They accumulate information about what happens in the field and use that information to understand behavior and then apply that understanding. The product is action-centric and business rules driven. It is configurable for their clients in a menu-driven (no code) way. They capture the rules for a specific client and define decisions – what to do when. These can be based on data in the system or on the predictions being made. These decisions can include the preferences of end customers too – TOA clients’ customers can be empowered to enter their own rules – about notification or channel choice for instance. These decisions could be to reschedule an appointment, assign someone else, send notification etc. Client policies and preferences are stored as rules and some of these rules are configured by business owners at the client site, some by TOA, depending on the sophistication and level of complexity. End customer preferences are stored as data rather than rules (which is a pity as it limits what a customer can specify) and this data is combined with the client rules to drive decisions.
The system is designed to be self learning, picking up what has happened (or not happened) to continuously compare planned v actual. Users can always see what is happening and client companies can see what rules fired and why over time. The system learns across staff and event types and has a high granularity – allowing it, for instance, to learn that product X takes a long time to repair. A robust optimization tool is included for routing and scheduling. Rules are used as constraints and the optimization takes into account historical performance and up-to-date information as well as the rules configured in the system. All the technology has been developed by TOA – nothing is OEMed – and they take advantage of the SaaS model to enhance it quickly.
Each decision integrates customer and company rules, weighting the different pieces. I have talked before about this kind of personalization through include customers’ own rules but this is the first company I have spoken to that is really doing it. They like to say that there is a myth in field operations that allowing customers any control reduces efficiency. The folks at TOA maintain the opposite and argue, convincingly, that excluding customers from a decision in which they are clearly a major player degrades efficiency rather than enhancing it.