One key way Array Web Development identifies trends in the business web-world is by looking at how often we're asked to provide specific services. Within the past six months or so, one request that's becoming more common is integrating corporate web sites with Zoho. This article introduces Zoho and looks at some common integration projects that a business web site can put into play.
For those unfamiliar, Zoho isn't new; it's been around since the late '90s in one form or another. Most commonly, it's used (at least by Array Web Development clients) as a CRM solution, a project management tool, and a sales cycle management suite similar to SalesForce. (Zoho calls themselves the "operating system for business"; see here for a breakdown of their offerings.) They started hitting their stride in the early 2000s and, by 2008, had a million users. However, this article is about current internet trends, right? So, let's look at some recent data to show the exponential growth of this platform lately.
By 2015, they'd ballooned to 15 million users, and by 2016, it was 20 million. I read somewhere their current intake is upwards of a million adoptees per month, worldwide. That's a significant hockey-stick curve there, and arguably indicative of a platform that was built with scalability in mind from the outset because, if the platform were sloppy or buggy, it wouldn't have handled that kind of exponential adoption by the business world.
When a company wants their web site to integrate with an outside system like this, that's done via an Application Programming Interface (API). An API, simply, allows one system to talk with another. For example, Flickr may store all of your personal photos, and you want those to appear on your web site in some way. Well, using Flickr's API, you can get your site to "talk" with Flickr. That could be something simple like retrieving single photos or sets of them in a gallery, or more complex like providing a portal for certain web users to upload photos to your Flickr account, all via your web site instead of logging into Flickr. Most APIs allow you to do pretty much *everything*, via your own web site, that you could do on the site itself (so long as you program it).
APIs vary widely in many ways, including their useability, their functionality, their elegance... Web development companies like Array Web Development are routinely called upon to make web sites talk with outside sites, via APIs, like Google, Youtube, Flickr, Authorize.net, Guidestar, HubSpot, etc. Most larger systems realize that they need to open up their data to allow such integrations, so most of them have decent APIs nowadays.
The tricky part is that, if you think of a system like Youtube as a database (which would have fields like video title, video ID, video description, keywords, etc.) and also think of your web site as a database (which would have fields like article titles, article IDs, authors, etc.), you can start to get a feel for how integrations between any two different systems, via these APIs, generally require a lot of custom "mapping". Mapping simply means matching up a bunch of different data.
Computers are unimaginably powerful, but they're also completely stupid. For anything and everything a computer does, it has to be specifically told to do it. So, to use a CRM-type example, when you have a new user sign up on your web site and they're giving you data like first name, last name, address 1, address 2, city, state, zip, and area of interest (as just one basic, rudimentary example of a CRM contact out of millions of possible such structurings that a CRM contact might have, depending on how you want or need your contacts to be setup), what you have to do is the following:
First, you have to make sure that all you're asking for on the web side is *properly* setup in your CRM system. So, you'd need those aforementioned fields in your Zoho CRM, and likely a lot more (such as the created date, maybe the user's IP, etc., etc., etc.). Then you have to take in all of that data via a script (usually PHP in the web world), and *map* it to your Zoho fields, pushing incoming data over there via, you guessed it, Zoho's API. You might also store it locally, which means you'd want a database on your local server to mirror the Zoho one. In the latter case, which is fairly common, you may run into situations where data may later change on the web site database, or in the Zoho database. If so, what happens then? Does it sync somehow? Does it sync one-way only? Does it sync both ways?
My point is that these APIs allow you to build out exactly the kind of interaction that's necessary to serve your business needs and processes -- but keep in mind that it all generally has to be custom-programmed to accommodate your business. So, when that new user (who usually starts out categorized as a "lead" in most CRMs) turns into a "closed deal", that's an example of something that has to be coded.
So, why are so many companies opting to integrate Zoho with their web site? I think one answer lies in all of the great tools that larger sales platforms offer in terms of lead management and reporting. While it's true that one could reinvent Zoho or Salesforce on their own site (and, in many cases, I actually actively recommend that!), it's also often true that many businesses share common desires in terms of business process, reporting, sales cycles, HR, etc. So, there's little need to completely reinvent the wheel when massively sophisticated tools exist out there already for the standard stuff you probably want or need.
Another answer is that the maturity of these APIs allows you to better manage your data via your web site. For example, if users register / login and do things on your web site and/or change their data (e.g., contact info), you can now easily update that info directly within your cloud-based CRM (Zoho). This is a massively convenient thing as compared with just 5-10 years ago when cloud-based CRMs weren't quite as mature and/or accepted by the business world.
Times have changed. At Array, we work with numerous APIs, as "web site to outside systems" integrations are fairly routine these days. It's still true, unfortunately, that some APIs are tough to learn, some are buggy, some are quirky, some rather unintuitive. But none of these things are true of Zoho's API; it's truly a thing of beauty, and quite a pleasure to code within that environment. It's one of those APIs where, as a coder, you think, "Hey, I wonder if X works here..." and, you try it, and indeed it does work. They've simply put significant effort into making their API intuitive, which is still somewhat rare in the high-tech world.
Beyond that, though, they've included qualities that force integrators to code things in a highly efficient manner. I'm not sure I could explain that in lay business terms, as it's all technical mumbo-jumbo that few would appreciate. But, when one system's rules (Zoho's API) results in your system (your web site) having truly elegant, fast-running code, it's a real win-win. So, if you *do* properly integrate your site with Zoho, it's probably going to be a clean, long-lasting integration, and thus chances of a positive ROI are excellent.
Hopefully this article painted at least a broad picture of what it means to integrate Zoho with your web site, but please feel free to drop us a line if you have specific questions about this. :-)