What were the top pain points that lead SpryPoint to create a customer information system (CIS)? How does SpryPoint’s solution resolve these issues?
Over the course of my first fifteen years in this industry, I suffered through a lot of problems that came bundled with traditional software solutions. As a consultant, my teams and I spent many weekends locked in server rooms performing costly installations and upgrades. Development and quality assurance teams struggled with regression testing and build management. Support teams struggled to gather information from systems outside their sphere of influence to reproduce and resolve client issues. As a result, utility customers had to wait for both features and bug fixes through lengthy development and release cycles.
Next, utility customers started asking how to integrate their information silos with other on-premise systems and emerging off-premise services. While legacy vendors saw some success in resolving a number of problems that the earlier generation of in-house mainframe systems had intrinsically suffered, a new layer of problems were being introduced with client-server and n-tier technologies.
When I started developing the vision for SpryPoint, it was clear from the start that the goal was not just to build another piece of software that calculates utility bills, but to engineer a company from the ground up to provide a fully-integrated software as a service. We looked to the pioneers of enterprise cloud technology like Salesforce.com and Amazon Web Services to see what separates the most successful cloud service providers from the also-rans. The technology and practices that we have since developed, allow us to build, test, deploy and support software in an entirely new way which gives us great agility and velocity in releasing features and resolving issues.
Over the last six years, we’ve built a dynamic team that works closely with our utility customers across North America. We’ve been fortunate to serve a lot of very progressive utilities and in doing so, have been able to push the envelope on innovation and capitalize on all the advantages a cloud-first architecture delivers.
When I started developing the vision for SpryPoint, it was clear from the start that the goal was not just to build another piece of software that calculates utility bills, but to engineer a company from the ground up to provide a fully-integrated software as a service.
Our customer support structure is completely integrated with our development structure, allowing our team to diagnose and resolve issues, and deploy new software not quarterly or semi-annually, but weekly, if not daily. In fact, we often deploy new features and resolutions multiple times per day, which has the wonderful side-effect of ensuring that our customers are never more than a few weeks behind the absolute newest version of our products.
When developing for the cloud, security was our first consideration, which has another great side-effect of ensuring that our solutions are also engineered to support deep integration with other cloud and on premise systems right from the start. We are built to work with other systems and services, which brings the intrinsic ability to enable communication between stakeholders such as customers, utility information workers, and field technicians.
Give me the details on SpryPoint’s CIS. How does it differ from other CIS’s that are currently available?
The ability to correctly calculate a bill, while critically important is not exactly a new concept. The same can be said for the ability to maintain a database of customers, or a ledger of accounts receivable. These are problems that have been addressed countless times by software engineers.
I see several major ways that SpryPoint’s CIS offering differs from other currently-available systems.
We began building this system from scratch after having spent decades working with hundreds of utilities. We have strived to design and build our solutions based on both what we have seen work and what we have seen fail in many previous software packages.
We have implemented a robust data model with capabilities designed to adapt to the future needs of any utility. The recent, growing demand to support communication with customers and other stakeholders, presents major challenges to legacy, on-premise applications.
We have designed our customer information services from the start to support holistic customer engagement strategies, with a CRM-like experience and inherent support for communication through email, text, and other communication media.
Where utilities might traditionally require several applications and a great deal of complex integration, we simply include all those components as part of the core product offering.
We designed the software and support structures to support scaling. To us, this means not just the ability to scale up to serve large utilities, but very importantly to scale down to serve the smallest of utilities. Over two thirds of the APPA’s public power members serve less than 4,000 customers. Our cloud-based technology and infrastructure affords us the ability to scale systems (and the pricing) to serve these critically-important small utilities with a level of service that otherwise might have been previously out of range for their budgets and staff. This, we feel, will help to democratize the market and improve the customer experience for many underserved utilities.
Perhaps the greatest differentiator for us is that we offer a fully-integrated service and support structure based on our software systems and modern software development practices. As we continue to grow as a company, as a product, and as a service, this structure will give us the ability to quickly implement and market features and additional product lines to support changing customer needs.
Can you give me an example of your ideal client engagement? What would their main issues be and how would SpryPoint CIS remedy them?
I think that the most important question on starting an engagement is “why”. Why are you considering the replacement of a software system? Our ideal engagement would be with a client who answers this question with a vision of integrating and improving customer service, seeking opportunities to work more closely with their customers rather than just fixing issues in calculating late payment penalties or meter reading import programs. Ideally, we want to be looking at how we can improve business processes rather than software features.
I think that the most important question on starting an engagement is “why”. Why are you considering the replacement of a software system?
We ask this question when introducing our products to any prospective client. Take our mobile field service product as an example. We will ask a prospective client, “Why are you considering a replacement of your paper-based field service processes?” If the answer is simply to reduce the amount of paper shuffling, we will use that as a starting point. Let’s consider that the paper service order is a communication medium, not a software system output. We are now talking about replacing a communication medium with a much faster and versatile medium, and this allows us to consider how, ideally, we would want to communicate with all stakeholders as part of the field service process.
We can expand this discussion to include real-time alerts and dispatching, SMS confirmations and scheduling with customers, and instant communication between office information workers and field techs. These are the areas where we really add value and change the customer service game, rather than simply representing a paper report on a mobile device.
The convergence to Cloud technology is an inevitability that many industries have already embraced. What would you say to the companies who are still hesitant to go with a fully cloud based billing solution?
I would hesitate to call cloud technology an inevitability for everyone. It is a very compelling alternative to on-premise systems, but only if it is embraced in the true meaning of cloud computing. I feel that many traditional software companies have tried to hijack the term “cloud” to mean “any computer program that is running outside your server room.” We have seen co-located client-server and mainframe systems marketed as cloud solutions although they are functionally no different from on-premise systems.
I feel that many traditional software companies have tried to hijack the term “cloud” to mean “any computer program that is running outside your server room.”
Over the years we have also seen several attempts at building semi-functional web-based front-ends on client-server applications for “light user” portals or rudimentary customer access. The key difference is that a traditional software package, one that was not designed from the ground up to be offered as a cloud-based solution, probably does not have the security and service integration capabilities in its DNA. The support and organizational structures are likely the same now as they were before building that web front-end. A true cloud solution is more than just software. As we have seen in other industries, cloud solutions facilitate evolutionary shifts in capabilities and expectations.
What is one piece of advice you would give to a decision maker looking to update their company’s current legacy billing system?
I would recommend that a decision maker take a look at the motivations of those that would instill the “fear, uncertainty, and doubt” in new technologies. Let’s assume that the decision-maker is considering the replacement of a CIS system that was implemented sometime after the Y2K rush, in say 2005. I would ask them to consider what has taken place on the broad technology scene in the time since they last looked at the utility CIS market. I would remind them that the first Android was released in October 2008 – less than 10 years ago. The first iPad was released in April 2010. Around 400 million smartphones are now sold per quarter, meaning that technologies that tough to comprehend in 2005 are now ubiquitous and in the hands of basically every one of their customers.
Today’s utility customer expect some pretty big things from their service providers, and a fear of new technology is not going to help address these changes. I would challenge a decision-maker to raise the bar of their expectations and hold their technology partners, new and old, to that expectation.