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:
- Our experience
- Our network
- Our favourite search engine
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:
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 staff members can see their last 250 calls, as well as duration – that’s the card on the top right. This card has an auto-filling search field, which will filter the numbers on the fly. The numbers are of course clickable and will initiate an outbound call.
- The card on the bottom right shows all queues that a staff member is assigned to. This shows the number of staff in that queue and how many are available, as well as service level and call statistics. If a customer is in the waiting line then it will be visible via a colour change.
- The cards on the left are individual calls and this is where the magic happens from a customer service perspective.
- The colour of the top part of the card indicates the call status (ringing, in call, on hold) and we can also view all recent calls that have occurred with that caller (based on the caller ID).
- In addition, we automatically see the customer ID and any current bookings that may be in the system. These are then linked to the internal Blacklane systems, meaning we can identify and access the correct booking much faster.
- If we have been able to recognize the caller ID, then we can automatically link the call card to the user account in Salesforce, allowing us to access any email communications directly.
- And finally (bottom right of the call card), we have the call categorization. The staff member must categorize the call, and the card will not disappear until it has been done. The categories vary depending on inbound or outbound, as well as the department that took the call. The data from the call categorization goes straight to Salesforce via an API call, and are automatically assigned to either the Account or Lead object
- The bar at the top allows the agent to change status (pause, available etc) and also has a combined dialpad & address book on the very right. Therefore the team members don’t need to remember extension numbers, but can just start typing the name of a colleague, or even a queue if they need to call another team or transfer a call.
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!