Why we built our own soft-phone

1st December 2016

In a steadily evolving world of technology, we have an overload of choice when it comes to systems we can use in the Customer Service world. Even integrations between various systems are no longer a challenge, and software (SaaS too) providers know that such features are no longer just “nice to have”. So where do you start when you want to increase efficiency, reduce the amount of tools/systems your staff is using, increase the visibility of data generated within Customer Care, or simply provide a better Customer Experience by implementing cross-channel visibility?

Most of us would use 3 sources to put a short list together:

This list should then be paired with our requirements. In my case they were the following 5 points:

1: Integration with our CRM tool and our own interface(s)
These points are simply necessary. When a customer calls, I want:
– the caller to be identified and the call logged in our CRM – The same should happen for outbound calls. This should happen automatically and the staff member shouldn’t have to trigger anything
– the staff member to be able to create a case/ticket with a single click
– to be able to go to the passengers account in our own system (if the caller has an account with us)
– to be able to see and go to the bookings that they have with us, as it is likely that they are calling us regarding one of these. We should be able to do this with a single click.
– to recognise whether the caller is a driver, and potentially take different actions based on them.
Please note that at Blacklane we refer to anyone that is not a staff member as a “customer”. This could be a distribution partner, a driver, a limousine company owner or an existing/potential customer

2: Flexibility
We’re a young company and things change fast. Sometimes things need to very quickly be adapted for/to our other systems,

3: Stability and quality
We currently use a soft-phone that is well known, free of charge and relatively stable. While this has been acceptable so far, we need to ensure the quality of service that Customer Service provides, and this includes the quality of the calls themselves. We are constantly in touch with customers around the world, and they may be on landlines or mobile phones. Our phone system cannot be a point of failure in terms of call quality.

4: Cost
Cost doesn’t mean cheap or free, it means we should be investing the correct amount for something that is raising the bar for us.

5: Usability
All of the above-mentioned points are irrelevant if the soft-phone is so complex that using it is a pain for the users. It needs to be intuitive, clean and fun to work with.
So before I get around to our solution, here is the environment with which we had to work: Our CRM is Salesforce. Our ACD and phone system is a self-hosted Asterisk solution, with a self-built admin interface with a normal setup (users in teams, teams assigned to queues, individual hotlines leading into those queues, queues with Service Levels and priorities. 2 other departments also use this setup beyond Customer Service). We use a self-built Chrome extension to auto provision the soft-phone. Our internal administration interface for all Blacklane-specific data is self built, and as it runs in the same environment as our PBX/ACD, it’s as accessible as via an API. This is what we are trying to reach:

pbx

We used our favourite search engine. We asked our network. We looked back at our previous experience with other phone systems, specifically soft-phones. And then we decided to build our own.

There are solutions out there that fulfill 4 of our requirements. The main hurdle we found was combining the integration with our systems AND being fast. It’s of no use to my team if a feature is rolled out to Blacklane, and for whatever reason, the soft-phone provider needs either too much time to adapt for us, or too much money. That may sound demanding and so it should. Service providers should be able to adapt to their customers, and that flexibility isn’t yet available everywhere. Admittedly, we have an advantage that we have some great talent on board, including some Asterisk experts that have experience in other (programming) languages. I’ll let them go into the technical details of what we did in a separate post, but here’s what happened from a “business requirements” perspective:

I sat down with the Customer Service Lead Team and we wrote down what we wanted in terms of functionality and what issues were causing concern. The summary of these is the list of 5 points above. In addition to that, we wanted to try and get away from installed software, to reduce issues with auto-provisioning and administration of users in multiple systems.

With this list, I approached our “guy for phone stuff” and validated the feasibility of each point. We had various conversations around how they could be implemented, and as usual, our ideas were transformed into better features, and we had an agreement on the direction we wanted to go. Back at my desk, this was put into a series of mock-ups, which served as the basis for further detailed discussions and refinement of the features. I was fortunate enough that I didn’t need to create any more mock-ups, the printouts of the original (with our scribbles) then sufficed as the requirements for a while.

Another point I should make here, is that the development of anything goes much faster when both parties know the details of the task at hand. We are/were in the fortunate position to be able to talk often and discuss details as and when they cropped up. I’m 100% sure this wouldn’t have been so easy in a large corporation.

So what did we end up with? A browser based (Chrome) softphone that doesn’t need provisioning as we sign in via a Chrome extension with our PBX credentials. The Chrome extension also adds click to dial functionality to any webpage (phone numbers are always clickable) and when clicked will open the correct tab or bring it to focus.

Let me explain the interface a little more:

The standard functionality that we need, such as initiating and accepting calls, transfers, conferencing or merging calls are there too, of course, as well as basics such as reporting. I’ve intentionally skipped over these parts here as they can be assumed.
I can also recommend, when implementing such an important tool/system, make sure you have the developer(s) close by, ideally in the same room. Apart from making the bug reporting and fixing process faster, it also makes sense for the creator and users to understand each others’ needs. Even though I manage the team, and put 95% of the requirements in place, it’s actually my team that will use the browser-based soft-phone, and not me, and as such, their requirements, specifically in terms of usability, are different. Lesson learnt!