How Cloud Processes Solved Our CRM Development Problems

DZone 's Guide to

How Cloud Processes Solved Our CRM Development Problems

In this epic tale of hope, heartbreak, and success, see how the cloud helped solve a nightmare problem during CRM development and how it might help you, too.

· Cloud Zone ·
Free Resource

Act 1: We Axed a CRM Solution Two-and-a-Half Nerve-Wracking Years In the Making

It all started two-and-a-half years ago, when we (an IT solution developer) decided to kick off CRM implementation along with marketing and sales automation for UniSender (an email marketing service), using a system from a big brand-name vendor. We soon faced nagging problems with the system: software failure, freezing up, interface failure, and many vendor-side bugs. Despite immediate tech support responses on our part, our sales department wasn’t able to offer direct help, and these persistent issues continually made our clients nervous. Long story short, we could do no right.

Furthermore, the processes for performing debugging for this CRM turned out to be a real mess. We were initially told that "there are no problems, you can do everything in the editor,” but, in reality, a qualified C# specialist had to write code using the CRM interface without the help of an IDE. And you know the old saying about bad things happening in threes? Well, this was certainly the case here. Testing and debugging were full of unknowns, and, on top of that, the system would frequently fail to work on mobile devices and when upgrading to newer versions.

In search of a better solution and working together with UniSender, we examined the CRM market, reviewing more than fifteen demo versions of CRM products. As a result of this review, we selected the Pipedrive as our solution going forward, which would allow us to transfer all CRM system logic to external modules, and to interact with Pipedrive CRM solely via API. Numerous other factors contributed to Pipedrive getting the nod, including its API and user interface, as well as its AWS compatibility.

Act 2: Full Automation Through a Cloud Process Engine

With thousands of people signing up for our service every month and performing tens of thousands of actions within it, we now had to find a way to handle this data stream.

We decided to use Corezoid as an engine for business processes. The visual flows Corezoid’s platform provides are much easier to maintain compared to writing code from scratch, and services similar to FlowXo due to flexibility questions. It was also impossible to integrate the UniSender service directly with CRM because of different data formats, and the need to write an additional script handler tasked with accumulating data from several sources. Corezoid worked as it could also process registration and payment data in real-time, rather than with delays as before.

Image title

To implement this plan, we made out a list of requirements and determined what should be modified on the UniSender API side. The following is a diagram demonstrating how we synchronize registration and profile update data:

Image title

Act 3: Overcoming Troubles Along the Way

In the beginning, we were keen as mustard about Corezoid’s features – it was the business-process engine we dreamt of: simple, intuitive, clearly arranged and reliable. We were especially happy with the professional approach of Corezoid’s developer team, who gave us advice, assistance, helpful hints, and were always quick to respond when we needed them.

Unfortunately, and for the record, we failed to create a fully 100%-visual Corezoid process. However, the code is contained in nodes, and, because it is not complicated, the process is clear not only to developers, but to managers and business analysts as well.

When it comes to Pipedrive, we were also satisfied with its failure-free performance, detailed documentation, and user-friendly interface. However, as far as we’re concerned, the further it goes the messier it gets.

First off, we detected that the Pipedrive API had significant load constraints – the system could not process packets (300,000 requests each) via API in a reasonable time. Because of this, it took us a week to upload the registration data. It taught our team a good lesson: when you try to connect to a system without having direct access to its database, you need to check the API capacity first.

Bulk data updates through Corezoid are not a good idea either, even though it seems like the easiest way. We finished the registration import process, transferred 300,000 entries into the DB table, while the iterator sends it row-wise to Corezoid in the form of a request. In fact, however, both system developers and our experience suggest using other tools, since the request processing itself is the most data-hungry and time-consuming operation in the whole process.

There are still the occasional bugs in the Corezoid PaaS, but, as a relatively new technology, that’s not uncommon. And, for development projects like ours, it would also be ideal to have a feature connecting JavaScript libraries to code nodes, which would help further reduce development time.

Act 4: Business Processes, 17 Million Requests, and Other Challenges

We also managed to automate some complex business processes aimed at analyzing customer data, activity, and service payment — and with subsequent reminders for managers to call or write to the customer. To accomplish this, Corezoid automatically checks the client’s "liveliness" within the service and indicates when we should do something if we don’t want to lose them.

The system helped us improve our relations with the customers using our service at the trial level. We installed an internal request timer to check the activity of each user within the service to learn whether the customer made the switch to a paid service package, and if they experienced technical difficulties while working with the service. In this case, an automatic support message would be sent to both the user and a manager responsible for offering technical support.

Image title

Our chief achievement is that we are now able to control, in real-time, the processes for registration and receipt of payment. The service sends a request to Corezoid, which completes the data and transmits it to Pipedrive. However, considering the number of registrations and payments within the service (as well as the number of profile update operations and requests to supplement the data in CRM) the overall load is very heavy. Fortunately, Corezoid processes all data in the cloud, therefore helping to alleviate the load on our server.

Halfway through our transition we found and fixed another “bug”: both the Pipedrive and UniSender APIs may "crash" at any moment and you will not always be unaware of it. During such a failure, the server – instead of returning error 50x – could return other errors (like, say, error 401, or even no errors at all). To solve this, the cloud process engine helped to collect all variants of API errors and create proper script handlers.

The following is a schematic diagram showing this process in Corezoid:

Image title

When comparing the time spent on this CRM project using Pipedrive and Corezoid with the previous CRM implementation, the Pipedrive and Corezoid implementation took 450 hours of net developing time, as opposed to 2500 hours spent on the previous system.

We now have a convenient, modern CRM system accessible from any device. We have also managed to pump up our cloud CRM — originally described as "CRM for small, but combative sale teams" — into a fully-featured CRM with business processes and data validators capable of processing a great deal of requests in real-time. In fact, currently, fewer than 10 managers are able to serve more than 100,000 service customers.

cloud, cloud automation, cloud processes, crm software development

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}