Productivity Certification Best Practice
I recently visited the glorious new Bloomberg offices in London and was just blown away by the whole experience. As you emerge from the shuttle lifts to face the massive tropical fish tank, you are personally greeted by dedicated friendly staff who greet you by name, provide an update on how far away your contact is, and invite you to sit, relax and help yourself to the large (free) pantry.
What an amazing first impression. What a service. And one that stays with you long after you walk back out into the buzz of London City.
If you have ever visited a WeWork shared office space, or stayed at a citizenM Hotel, you may recognise this level of service, attention and that great first impression. But what you may not initially realise, is that for all of that feeling of service and attention, the experiences are actually self-service by design. You help yourself to snacks and drinks at Bloomberg. You check yourself into a WeWork and a citizenM hotel. So despite being self-service, so why do we feel so positive about these experiences?
Well, there have been a number of studies now, which have found that people show an increasing preference to do (and learn) certain things themselves; a natural reaction to the constant information overload and sales "noise" we all experience every day. We no longer want to deal with the rental car clerk who tries to sell us all those expensive add-ons; we just want to pick up the car we ordered online. We don’t want to be cold called by software vendors; we want to learn about products online and contact them once we need help or have already determined that the product can help.
So how does this relate to our little niche of API management and conformance?
Well, the vast majority of new customer connections follows a strikingly familiar pattern which leads to a decidedly mediocre first impression. As a new customer, I’m emailed a PDF specification (or asked to register with some portal to download it) and an email or phone number for questions. These are forwarded to a developer who then struggles to get connected (firewalls, networks etc), struggles to send and receive messages, and struggles to understand how the messages match up with both the functionality descriptions in the document and the workflows in the system they are trying to connect.
At FixSpec, we’ve been championing the idea of increasing automation in this process since Day 1; giving your customers better, clearer and more accurate documentation to accelerate their development cycle, and offering tools for both order originator and recipient to automate the validation and certification of messages. This includes both internal tooling for the service provider (bank, exchange etc) and self-service tooling for the counterparty.
Unfortunately, we often meet folks who start out with the unrealistic expectation that these tools can fully eliminate the need for internal staff to assist customers during onboarding for at least their "less valuable" customers. When viewed through from this perspective, internal tooling seems irrelevant; only a full self-service tool can achieve their objectives. We obviously disagree and believe that this mindset is the principal cause of poor (and frustrating) experiences around self-service portals.
While the outcome of these projects often falls short, the overall objective of increased efficiency leading to greater capacity, shorter onboarding times, and spending less time (and cost) while serving each is spot on. But there is one crucial ingredient missing which becomes obvious when compared to the "onboarding" experience of visiting a Bloomberg, WeWork or citizenM location. It's the greeter.
Greeters at Bloomberg, WeWork and citizenM are not there to check you in or print a pass. It is their job to make you feel welcomed, orient you, and answer any questions you may have. They are helpful, knowledgeable and informed. It is this combination of supported self-service that works so well and leaves that lasting impression.
So how can we make API connectivity more like that experience? Here are some ideas:
The principal task of "onboarders" should change to become a "functional consultant"; a super helpful, friendly person capable of describing the functionality of the system and not just the messages. This means they should know the precise workings of the matching engine or trading algorithms and be able to explain them in plain language and how they may compare to other models the customers have seen.
Their focus should be on helping the customer understand the service and not just API messages. This includes explaining workflows and working with the developer to match these up to their internal functionality.
The first contact should be from the functional consultant TO the developer, and not the other way around. In other words, the developer should feel both welcomed and know that there is someone there who is actively offering to help.
Functional consultants should - wherever possible - work on a particular set of customers, to ensure that they have a constant point of contact that they can rely on. Internally, the consultants should record all customer interactions centrally, and share this with other team members, ensuring that if one team member is ill or on holiday, any other member can step in and have all information at their fingertips.
Just as greeters don’t spend their time registering guests, so functional consultants should not spend their days grepping log files and dealing with mundane tasks. These should be automated to make sure the consultants have fast access to the data they need. This is the value of great internal tools.
Consultants should be pro-active, meaning that they should regularly keep track of customer progress (i.e. watch activity in test or development environments even when the customer doesn't call), and check in with the customer if they see problems. Consultants don’t wait for the customer to call - they pick up the phone to offer assistance before being asked.
Consultants should be a point-person for all requests from the onboarding customer. They should never palm them off to a different department even if they can not directly help; instead, they should take responsibility for the task and work internally to get it resolved.
Crucially, the end-to-end experience must be deliberately designed and repeatable. This isn't just about hiring helpful staff or telling them to ask how the callers day is going. It is about walking the process in the customer's shoes and challenging yourself about ways to continually improve it.
When positioned like this, the importance of internal tools becomes clear; without an internal system, the Bloomberg greeter would not have seen my photo to be able to greet me by name, just as Functional Consultants without a monitoring tool wouldn't be able to immediately explain why a FIX message was rejected.
This model is also scalable depending on your customer pipeline. We often meet firms who run onboarding from their general support or operations desk. That's great, and works perfectly with the Functional Consultant concept here; a central, helpful team who can stay with the customer right from their original connection through their ongoing business relationship. If you grow to a size where the teams split up, then make sure that the handover is as smooth and effective as it can be.
The final - but important - piece is that this experience should be available to ALL customers, no matter how big or small. Make all customers feel welcome and valued because they are.
Now... isn't that the first impression you would want to leave?