Zoho CRM is part of a suite of office software tools made by Zoho Corporation, an Indian multinational technology company. It is relatively inexpensive in terms of costs per user, but has lots of functionality. The client already had Zoho CRM, Analytics and Campaigns (as it then was), and subsequently added Zoho Books to do their accounting too. They were keen to add a supplier bidding platform, amongst other things.
The first thing was to check out the capabilities of Zoho CRM, and how easy it would be to build on new bespoke functionality, as well as encouraging the users to use it as a CRM rather than just a month-end management reporting tool. Zoho CRM is readily customised. It is easy to add new “modules“ (which hubspot would call objects and I would call tables) and the normal components are there to add new fields [properties], build input forms with standard field types, and columnar data to be browsed. More importantly from my perspective as a developer (and in this case interim CTO), is that it has an API and a ready made SDK (Software Development Kit) for php and other languages to ease calling the API. This is as well, because the sales side of the CRM was designed for selling physical products and not services. We ended up junking all the sales order processing components and re-created them with our own custom “modules” to get around this.
The CRM has its own “Deluge” scripting language, where scripts can be triggered by actions such as submitting a form, or by buttons that can be added to the users’ environment. This is a JavaScript-like language which can be used to update field values, create and send emails, or call http services. This is very powerful, in that you can then call your own APIs across the internet, which can take actions, return results through the http call or use the Zoho CRM API to update the CRM data directly, attach files etc. Here some things we did with this:
o Send emails to suppliers asking them to bid on work. Create custom web landing pages with the job details and directly insert the quote values into the Zoho CRM database which then triggered various confirmatory emails through their workflows. Quotes could be compared within the CRM, and picking a winner would trigger another set of emails as well as pricing the job.
o Structure the sales form with the selectable parameters of the data that was being sold. Database counts could be returned in real time. A deluge script attached to a button would call php code which would read those parameters through the Zoho API and create a query of the MySQL database holding the data that was part of the product offering. Any targeted account or suppression lists attached to the deal would be incorporate in the query. The counts would be returned as a pop-up box, but also written to the deal record. The option was also there to return the data, in which case it would be attached to the deal record as a file.
o Where other external services with APIs were used, we ran cron (timed) tasks to get the status and update job records in Zoho so salespeople could quickly respond to customer queries on the progress of orders without having to login to other systems or constantly interrupt the operations team.
However, all was not plain sailing.
As per my blog on CRM customisation, the prepared link to Zoho Books did not work because we were not using their sales order processing components.
I got the feeling that Zoho had put all its development effort into the breadth of its suite of applications, and that some of the things that users were asking for were not being attended to. To its credit at least there were community pages where users could share experiences and possibly program code, unlike some other packages that seem to want to shut down any communication less flaws are revealed. Documentation was not always current, or old documentation had not been maintained, so there was often some ambiguity on what was right. Support questions of the more technical variety would get answered within a day or two, but there were times the application or components of it might go down for a protracted period. So overall, cheap, powerful, but scope for improvement in support. I would hope by now that they would have added the ability to process sales orders for a service, and I note there is now a facility to add client script that runs as JavaScript in the browser which should allow detailed customisation before the submit button is pressed.
As I have noted, the more intractable implementation issues are behavioural. We always struggled to get salespeople to use the CRM as their working tool. The organisation historically focused on whiteboards as a motivational tool, an approach that senior management knew worked for getting the deals in, even if it lead to a lag and subsequent errors on data input. The pandemic helped reinforce some of the points I had been making about whiteboards and post-it notes.
Extending the functionality of a working application can be a bit like upgrading a working road. There may be periods of one-way traffic or going the wrong way around a half-built roundabout before you are able to open the new dual carriageway. Similarly upgrades to a working SaaS system may be a multi-phase project, where new functionality is made available in fits and starts, risk is reduced and customer tweaks can be incorporated in the next release. However, not all users may be as agile as the team implementing the changes, and some sales people under pressure will reject anything that does not immediately help them close the current sale. My job was to create the technology, their job was to sell. I don’t think we ever budgeted enough time and effort (or carrot and sticks) to bring all the sales force with us.