When IT folks hear the term ‘integration middleware’, they usually think about a tool that works somewhere deep in the background, pushing data back and forth to support business processes. But what if an integration middleware is used as an instrument to build an entirely new product or increase added value of an existing one?
Just last month we showcased this trend in our webinar with the CTO of Star2Star, a US-based telecommunications company. He explained how his team used an integration middleware that supports the API-first approach to create an enterprise-ready communication platform as a service and bring it to the market faster.
This week, we’d like to share with you an interview with another telco company, based in the Czech Republic. Martin Olexik, Product Owner at IPEX, explains how a cloud-based integration middleware allowed them to redefine their already existing tool for unified communications.
I understand you have several products. Which one exactly received the ‘integration middleware boost’?
This is our product called Communicator, which is used by end customers for calls, chats and video meetings. In other words, it is a multifaceted unified communications tool. You can use it in your browser or download an app for Linux, iOS and Windows.
What is special about this product is that it is actually a white-labelled solution for other telco operators. In this sense, we are not an ordinary telco company. We prepare everything necessary for the administration and maintenance of this service, and then offer it as a package to other companies, which can then adjust its look according to their own corporate colors.
Another special feature of the Communicator is its Presence Bot, which is, generally speaking, the database of presence. It is connected to various systems of presence checking whether you are available at the moment of an incoming audio or video call. If you’re not available, the caller will be suggested to leave a message, call back later or request a callback.
How does the new version of this tool differ from the previous one?
We’ve been offering our PBX solution for many years, and the Presence Bot was part of that solution too. Now we are working on a new PBX that will be smarter and faster. We’re also working on a new Communicator, for which the Presence Bot would need more presence information sources to check. The old Presence Bot only checked the PBX, the [old] Communicator, and the Outlook Calendar, which was simple. This time we have at least 5-6 more sources to connect to the Presence Bot, for example, the Google Calendar.
In addition to that, we want our tool to be easily connectable to more CRM systems. We have already had integration with SugarCRM and Salesforce, but nowadays this is obviously not enough. So, we decided to work on enhancing the integration capability of the Communicator with multiple different CRM systems.
What was the reason for the product upgrade?
It’s about business. We wanted to deliver a high-value product to our customers, something that is likely to address more than just one of their business needs.
[clickToTweet tweet=”A good product needs to address more than just one of your customers’ #business needs. #BizDev #tech” quote=”A good product needs to address more than just one of your customers’ business needs”]Compare the Communicator as just a communication tool with the Communicator that additionally, integrates with a CRM system. The first one is merely another means of communication, and its target segment is service-oriented organizations, which is kind of narrowing-down.
The second one, however, allows you to initiate a call from a CRM system’s interface, it shares a call history with your CRM, and displays a caller’s ID card from the CRM system right in the Communicator’s interface. This solution is a great fit for Sales, and every organization has a sales force in-house. The tool’s implementation and usage are no more limited by a certain target segment.
What role does a cloud-based integration middleware play in this project?
By equipping our Communicator with an integration middleware, we allow end customers to use just one system for a wide range of processes, as opposed to using several systems for each type of process.
[clickToTweet tweet=”It’s just a better #ValueProposition: give ur clients an as much all-round product as possible #telco” quote=”It’s just a better value proposition: give your clients an as much all-round product as possible”]We integrate our new Communicator and Presence Bot with different CRM systems, like SugarCRM, Salesforce, Microsoft Navision, and with various systems of presence. However, now we’re planning to use this integration middleware for other projects as well.
For one, we are thinking about rewriting our internal order system that sends orders from our several frontends to the backend. It involves quite complex workflows, with several systems activated by this process. So, mapping these workflows in a cloud-based integration middleware seems like a good idea to reduce the complexity and maybe even speed up the whole operation.
This integration middleware you’re talking about is a third-party solution. Why didn’t you keep all the integrations ‘in-house’, why build them on an external platform?
We thought of doing all the integration work ourselves, and I must admit that we even tried to do just that. But we learned quickly enough that we didn’t possess the know-how, nor had we, to be honest, the capacity for that.
In theory, we could persist on building all integrations in-house, but then we would have had to stop all other projects; projects that have far more business value.
[clickToTweet tweet=”‘We could have built integrations in-house, but we would have had to stop all other projects’ #telco” quote=”‘We could have built integrations in-house, but we would have had to stop all other projects'”]Plus it is really simple to prepare new integration components in this system, compare to our standard programming. All we need to know is what our flow is.
Any final thoughts?
A cloud-based integration middleware that is already there for you to have it is a win-win situation for us and our end customers. As a team behind the products, we can now focus on adding value proposition to those products instead of developing a system that is not part of our core business offering. And for our end customers, it’s about more functionality in one and the same system.
