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.
First steps being the hardest ones ...
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.
From immobilized bricks to agile development ...
Paradoxically, the history of software partnerships is above all one of fragmentation - and thus at the same time tech history and methodology. Sound convoluted? It is - but only a little. Digitization is a development that takes place on many levels that are mutually dependent.
Up until the 1990s (and sometimes beyond), it was common to think of software systems as monolithic. Which only sounds like mockery in hindsight; it was the prevailing paradigm: software was thought of as a system that was supposed to encompass or map specific applications and requirements. These could become complex and extensive, but solutions were sought in one system.
Perhaps one of the most famous (and notorious) examples is SAP. The software manufacturer creates systems for handling business processes across all possible department levels - controlling, procurement, accounting, warehousing, logistics, HR, ... if you want, you can try the complete business model of a large international corporation in a single SAP - map platform. However, such attempts have failed spectacularly several times. Which is not only, but also due to the complexity of such projects, which are never just of a purely technical nature - personal ambitions, compliance issues, legal, political, hierarchical problems play roles here, right through to exchange rates, administrative guidelines and the like. That means: Building systems that map all of these questions needs a LOT of planning, ultimately a LOT of development time and then the whole bang has to be implemented, users trained, the whole story documented - phew ...
However, over the past two decades, companies – or in particular individual business units – have recognized a central requirement that is in stark contradiction to this: flexibility.
Not only because careers today are much more diverse, less straightforward and you cannot rely on the personal stability that long-term software projects entail, but also because the entire market environment has become more fast-moving, clients must have the opportunity to make changes ( “VUCA”) to be able to react.
Adaptability to changing market conditions is the somewhat cryptic keyword. Such monolithically planned and implemented software projects cannot guarantee this.
Monster software projects that fail with a bang are impressive proof of this.
One answer that the market has found is greater fragmentation: software providers specialize in perfect solutions for parts of the value chain instead of the supposedly big picture.
... under which a number of methods of work organization can be subsumed. Many of them have one central maxim in common: work must be broken down into transferrable packages. The often-cited transparency and efficiency are epiphenomena here: Transparency - often reflected in everyday work by meeting cycles and corresponding tools such as ticketing systems - is a pure necessity to ensure transferability in the event of staff fluctuation. And when it comes to efficiency, it's not that far off.
Nevertheless, the agile development methods, which can be considered generally established at the latest with the popularity of the Agile Manifesto, have a striking advantage: they make software development flexible. Requirements are broken down to building block levels and modules of a common project can be processed at the same time, from different ends and simultaneously. This is also accompanied by a paradigm shift that refers to the word “finished”: users are confronted with unfinished apps and software modules (“increments”) in order to test them and give the development teams feedback: Is the path taken correctly? Does something other than originally thought have priority? Did we misunderstand each other somewhere?
The answer: a construction kit
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.
APIs - what holds the digital world together inside
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.
The Value of Partnership
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:
- Companies that address common target groups with different focuses join forces and offer their software as a package or at a discount. Examples: CRM, CMS and newsletter software. Or companies that are traveling in different regions with a related offer - these can get a foot in the door of the other through sales partnerships.
- In the hotel industry, specifically with us, something similar is happening: For example, HQ revenue provides meaningful data including presentable visualizations to hotel consultancies all over the world. They can blindly trust the up-to-dateness and quality of the data, which gives them a time advantage. In return, our visibility increases.
Conversely, HQ revenue feeds data from third parties into its own system - we retaliate with the contextualization of this.
What's in it for our mutual customers?
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:
HQ revenue software partners
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.
– Florent Manotta, CCO at N&C
– Mano Ladhar, CHBA, Global Partner Manager, Global Alliances
HQ revenues consulting partners
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.
Relationship Guide: Who Makes the First Step?
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: 😉
You May Also Like
These Related Stories