Partnerships are an integral part of the SaaS world - for good reasons. Software partnerships are not only valuable for the respective partners themselves, but even more so for the customers. Call this polyamory, call it APIconomy ... there's some history, too.
So ... we have to talk.
The much-cited digital transformation has greatly changed the requirements for software and thus for software manufacturers. Software is being developed faster and faster - which has led to more pressure to innovate.
Providers can no longer do everything as generalists, but focus on specific areas. This has fragmented the software market – and made it simpler at the same time. Because one thing has not changed significantly: software development is expensive. It must therefore take place in a targeted manner - and the risk must be carried on many shoulders.
Partnerships are therefore not just a business advantage for the respective partner, but a simple necessity from which mutual customers also benefit.
Development fragmentation and market fragmentation are two sides of the same coin. On the positive side: We see greater specialization as the software providers' answer to the more complex market.
Because from the user's perspective, it is of course not enough to have a special solution for every special problem - the solutions have to talk to each other. The times when this was not a matter of course are still remembered: Many of us once spent hours printing out delivery notes from the ERP system, for example, only to enter the data manually into a table that we gave to the logistics provider.
You can still admire some incremental intermediate steps today - take DHLs' upload service for bulk mailings as an example: Here you can upload an XLS file that has to follow certain criteria and a certain form so that serial stamps or bulk mail can be sent online.
Which means that you first have to export this data from your source system and bring it into this form. Which in turn means a certain amount of manual work.
But: This actually illustrates quite well what APIs actually are. There is always talk of "programming interfaces", which is a somewhat strange term. APIs ensure that data from one system is passed in the form required by other systems. They systematize, categorize heaps of data. As a result, different systems can interact with each other - for example, a merchandise management system with a logistics system.
The more standardized the systems and the data they use, the more “generic” the APIs can be. An example of this is Zapier, a popular web-based automation tool that allows users to create workflows between different web applications. With over 3,000 integrations, Zapier makes it easy to automate repetitive tasks and streamline workflows.
The more complex or peculiar, i.e. more unique, non-standardized, the data bases that are to be used by several systems, the more complex the API becomes, and the more intensively it has to be adapted - i.e. programmed - for the respective purpose.
In any case, the API became the glue between all the individual solutions - and with it the APIconomy, which arose from all the developments outlined here.
Ultimately, for customers, it's not so much about the technical debate: Should something work as a large, encapsulated system, or should we build an IT architecture from different, mutually compatible solutions? In the end, it is about mapping, and solving the respective problem - and that business requirements are not neglected, i.e. that the solution is flexible, adaptable and also calculable in terms of costs. Which in turn again leads to modularity, agility and microservices.
Partnerships are therefore essential for SaaS providers. Partnerships allow software manufacturers to focus on their respective expertise and core competencies without losing sight of the market:
Conversely, HQ revenue feeds data from third parties into its own system - we retaliate with the contextualization of this.
Well: The best result comes about when everyone takes care of what they do best. This is how teams work - at HQ revenue we are therefore incredibly happy about our partner network:
Software providers such as revbell, GUEST, BusyRooms, IDeaS, duetto, Avalon Cloud or res:harmonics focus on their respective special markets. They each receive different HQ revenue data packages, which they process in their own way and thus embed in their systems.
Customers hence benefit from the best possible data – integrated into the system they are used to and that has proven itself for their use cases and ways of working.
Consulting firms such as berner+becker revenue management, Adi Ohayon Revenue Experts, AG Hotel Consulting or Brandnamic depend on having reliable and up-to-date data available for their respective target markets, regardless of how they are clustered - by region, by market category or by thematic focus.
Most of our consulting partners use the HQ revenue APP and the market reports as tools for their daily work. Clients can trust these consultancies to do their homework and can outsource this work.
First dates can be exciting in both a good and bad sense. This is no different with software partners. As in real life, at the beginning it is about whether you can find common ground: Do we see any potential for a real relationship? Or do we even go home before making out?
If we discover common potential, whole fireworks and even small children's products can come of it. If not, hopefully we still had a nice time together.
And so that it doesn't get too awkward for you, dear readers (we're open to that), we're taking the first step and inviting you to our app. We cook something nice for you from market-fresh hotel industry data. There is also a colorful bouquet of interfaces. And hors d'oeuvres of glazed AI. Yummy!
Too straight forward?
Ok... then let’s just say you choose the date and we meet on a neutral ground, in a Google Hangouts: 😉