Native vs Non-native CRMs- Do Utilities Want a Middleman Handling their Data and Operations?
WRITTEN BY JESSE HITCHCOCK, ANGELICA PEREIRA AND DEEPESH KUMAR ∙ TORONTO, ONTARIO
It is well-known what a middleman is: he is a man who bamboozles one party and plunders the other.
The mid-late 90s ushered in a period of incredible success for internet companies. Think of organizations such as Google and Amazon, writing the rules of the internet age. But along with it, came several companies writing a completely different set of rules -- on how to build castles in the air. While Google was building a search engine, Kozmo had convinced the world that free home delivery of Starbucks coffee was a money minting idea. That companies like Kozmo.com and Flooz.com with their surprisingly hollow fundamentals were entertained -- would have been so entertaining had the arising dotcom bust not been so appalling.
Spurious nonsensical solutions have managed to tag along with every innovation cycle since the history of human-kind. So why should it be different for the SaaS age? Companies with minimal technical depth are now building technical solutions on top of existing software platforms they don’t understand, for use cases that they have little grasp of, for a future they don’t necessarily care about. Welcome to the age of “Wing it SAAS” comprising companies that excel in selling someone else’s car to buyers looking for a truck. Metaphorically of course. The situation would be amusing, if it wasn’t downright alarming.
Case 1: Imagine you want to obtain an MBA. Would you attend a reputable business school or study entrepreneurship at a medical school?
Case 2: Imagine you have to buy an off-road vehicle. Would you buy a Jeep Wrangler or a lifted Toyota Camry with large wheels?
Case 3: Imagine you had to take an international flight. Would you rather the pilots be employees of the actual airline or outsourced contractors of a third-party operator?
Exactly!
Getting the foundation right is critical. CRMs are supposed to last long.
Why then do it with software?
There are instances where an off-the-shelf software solution is built on a third-party platform. The ride-hailing company, Uber, built their platform on the underlying architecture of Google Maps. What if Google started charging a hefty per user premium for map functionality? Or worse, what would happen if Google decided to shutter Google Maps altogether? Uber’s solution would cease to function and would require either the company shut down or spend several months building out their own native architecture; both scenarios would be disastrous for the company. Find the list of products Google has killed so far here.
The Alternative: A Fully Native Software Solution
If purchasing a software solution built on a third-party platform seems unnatural and even risky, the alternative is simple; software running on an architecture built from the ground up. A fully native software solution can be specifically tailored to targeted vertical industries (ie: energy efficiency programs) and allows a vendor to have much more flexibility around delivering functionality. Visualize a CRM automatically processing home-audits (H2K) files with a single click. Native platforms allow to drastically reduce onboarding needs and timelines.
Where non-native software solutions fall short
Non-native solutions present several key risks to both a vendor’s business model as well as the ultimate end-user of the product. With the underlying architecture of native solutions based on internal company design, security and flexibility are key advantages over non-native competitors.
As a subtenant, you haven’t interacted with the landlord, don’t know their plans but your situation heavily depends on their decision-making.
Cyber Security Risk - If we think of a retail store in a shopping center, picture SaaS as a brand that just opened a store in the mall. The security of the mall lies in the hands of the property owner. Brands do not get to control who the security personnel are nor do they get to define the security policy; this places a significant amount of trust in a third-party agent. Security personnel, who are hired by the property manager don’t necessarily have allegiance to the brands which creates a conflict of interest. Not ideal for security-sensitive organizations. If the brand were to build their own store on a parcel of leased land, they would have full control over the security personnel and policy of the store. Similarly, SaaS built on third-party architecture is reliant on external cyber security frameworks. SaaS built on native frameworks has complete control over security policies, access rights, and alert triggers. When protecting data is of utmost importance, SaaS based on native architecture is the most robust solution for industry verticals with specific needs like the Utilities, Government or Healthcare.
Pricing - Native SaaS pricing is only dependent on the agreement between the client and the SAAS vendor. Clients do not incur unforeseen costs for predictable events like an increase in user uptake. Non-native SaaS solutions, however, are dependent on pricing defined by the third-party vendor. As these third-party vendors increase their pricing, the price of the SaaS built on them rises as well. If you are a subtenant, the tenant can’t guarantee your rental price longer than the duration of his/her contract with the landlord. Certainty in your living situation is dependent on the Landlord. As a subtenant, you haven’t interacted with the Landlords, don’t know their plans but your pricing situation heavily depends on their decision-making. CRMs are not intended to be bought for 2-3 years -- they are meant for a lifetime, especially for utilities and governments. That makes price certainty a key ingredient.
Integration Risk - Every utility has its own set of unique requirements, integration is key for them to take advantage of the number of systems that connect their different departments. Native platforms can be upgraded and integrated into any system exactly as required by the utility. As utilities grow and expand their energy efficiency efforts, smooth integration leads to effortless scalability in functionality. Systems dependent on third-party solutions are constrained in the integrations they can offer. The risks have frequently played out much to the chagrin of the helpless end user. A recent example is that of the leading e-commerce vendor Shopify cutting off access for Mailchimp (prominent Marketing Automation Solution). For CRMs, difficulties include inconsistent email sync, email automation processes that fail to trigger and unclear and/or inadequate documentation detailing the various interactions between the two solutions. Issues such as these can have a detrimental impact on daily operations and reduce productivity and employee satisfaction.
Zynga is a good example of a rising vendor who suffered dramatically after Facebook changed its news feed algorithm. And many vendors got hurt when Google decided to kill Google Cloud Messaging (GCM). Non-native SaaS solutions depend on features offered by their third-party vendors.
Native SAAS can provide functionalities tailored for an industry vertical from ground up
Feature Risks - Zynga is a good example of a rising vendor who suffered dramatically after Facebook changed its news feed algorithm. And many vendors got hurt when Google decided to kill Google Cloud Messaging (GCM). Non-native SaaS solutions depend on features offered by their third-party vendors. Third-party platform vendors will follow their own product roadmaps, potentially eliminating or modifying key functionalities provided to non-native SaaS vendors. The elimination of key features and functionalities is a major risk in the stability and proper functioning of a SaaS solution. Native SaaS vendors have full control over the functionalities embedded within their solution with the ability to communicate, to end-users, any major changes well in advance of the update cycle.
IT Support – Any critical IT issue encountered with the underlying architecture will result in end users dealing with two layers of customer support for a non-native SaaS solution. Critical architecture issues will need to be escalated to the third-party provider, which presents the potential for significant delays in reaching a resolution. Or no resolution at all. Difficulties in issue resolution further highlight the lack of control over the full SaaS solution that non-native companies face compared to their native peers.
In the search for a solution that best fits the complexities involved in unique and specialized use cases, organizations need to not only consider superficial functionalities but the architecture upon which these functionalities are being run as well. Minimizing security, integration, feature and support risk along with having complete transparency and visibility into pricing should be front of mind for companies evaluating SaaS solutions.
Native SaaS vendors have full control and understanding of the solution provided, minimizing any potentially detrimental hiccups. Implementing and running software that supports daily tasks is a large undertaking and dealing with two entities, the software vendor along with their third-party architecture provider adds unneeded complexity. Native SaaS solutions cut out the middleman and offer companies end-to-end control over their product experience.
