API or Purpose-Built System. Which is the best choice?
It’s like gladiators vs. lions. Or Spartans vs. Greeks. Or something slightly less dramatic perhaps. Should you stick with what you have and add some API connections to increase functionality, or change applications and switch to a system which ‘does it all’?
Like anything, there will be pros and cons to either option and will depend on what your priorities are. Let us give you a little food for thought to help you find your way.
If you don’t know what API is, please see our earlier article here before reading on.
API can offer more
Generally speaking, this is true if you want a deep or broad level of functionality. For example, many travel systems offer CRM. However these won’t necessarily have the ease of use, in-built email and sales functionality or level of reporting as a purpose-built CRM such as Hubspot. The reason being that an awful lot of time, money and concentration has been spent on that sole product to improve, innovate and enhance, whereas within the travel system it is a smaller part of a greater whole (I should note however, CRM is becoming one of the areas of prime importance and travel systems are focusing more of their attention on this to take advantage of the way people now discover travel opportunities. CRM is just an example of a commonly accessed API).
API can slow you down
This is more apparent when you are using API to enhance the functionality of your websites. The reason being your request is pinged off via the API connection, has to wait for a reply and can then if permission is granted return the data. This takes time, although we are still talking about a second or two. On a website though, where surveys consistently show that people will usually only wait 3 seconds for a website to load, an over-reliance on API is enough to cost you potential clients. These API connections include integrated maps, social media feeds and links, chatbots and so on.
Within a system, this is less noticeable but again an over-reliance on API can slow down your workflow, creating those awkward empty pockets in the middle of your sales camaraderie or lose a client altogether if the data fails to be accessed immediately and they have to ‘return later’.
API can be riskier
Again, the risk depends on the product you are connecting to. For example connecting to a product primarily designed to be linked via API to other software carries a lower risk as pulling this would severely limit their product’s usage. Products such as Sage Pay, Amadeus are such examples of low-risk API connections and as such are not much higher risk than your Central Reservation System collapsing.
Other APIs carry a higher risk, especially if you are relying heavily on one for functionality. Google are notorious for suddenly pulling API connections to products they no longer want to support but which people are still using, the most recent being Hangouts.
The rule here is tread cautiously and have a back-up plan!
A system works better
This can certainly be true in two ways.
The system will have been designed to fit together and therefore the workflow will be more streamlined and integrated. There will be less of the annoying little knots where data is either lost or transfers incorrectly, often a result of two systems trying to communicate in different languages despite API acting as an interpreter. While those knots can be smoothed out, it takes time, effort and then someone will run an update and suddenly there is a selection of new kinks to untangle!
A system will also be purposely built to fit your specific industry. A connection to a general system will work very well, but does it record all the information you really need? Travel CRM for example has very different needs to a standard marketing and sales CRM. The sales process is completely different and marketing is a long term game of building relationships not short term as with most other sales arenas. Recommendations from reviews, friends and family also play a larger part in travel marketing than in other industries. A purpose-built CRM would reflect this.
We are not going to draw any major conclusions for anyone here. Each company’s requirements will be different and therefore to choose one over another would be pointless in this article. Hopefully however it has given some key points to think through before your next technology purchase.