Can you have FIX automation without self-service?

The answer is yes, but you can only get so far. There is a natural stopping point where an action needs to be taken by your connecting customers. And this requires an interface through which a customer can interact with you. For many firms today, this comes in the form of a documentation library, sometimes behind an authentication wall, sometimes not, depending on the type of firm. The information is there but it is not interactive or very navigable. The better alternative is a customer Developer Hub, but I am yet to see one that provides a significant level of self-service. The lost customer will still have to pick up the phone or raise a support ticket.

In a recent poll on LinkedIn, we asked what people would put in a connectivity Developer Hub, and the results confirmed that most saw it as a document library and a knowledge base. This response is hardly surprising as the few portals that we have seen in the market are generally limited to these elements. The feedback from connecting customers, however, is this simply acts to authenticate the document library and moves the information behind a login. All the other connection pains still apply.

A portal can go much further than this. It can be a tool that guides customers through the whole onboarding process step by step. And once they are connected, it can provide ongoing support, upgrades and regression testing. The onboarding team are of course on-hand to answer questions about more complex functionality and nuances that make the firm unique. But a portal can cut out all the repetitive noise that seems to fill many onboarders’ days.

Putting the customer in control:

In a previous article, I outlined the inertia around the onboarding process and customers have become accepting of the status quo of PDF instruction manuals. I know firsthand that this is painful. Both customers and venues want to see change. With an increased focus on customer and developer experience, a Developer Hub can lead a customer through a series of steps to connect, giving them back control – when customers log in for the first time, the screen will display what they need to start the process. The user then sees the relevant information at the right time and can trigger each element of the process on their schedule.

I am not suggesting a world where onboarding teams no longer speak or interact with customers, merely that these interactions are limited to explaining complex functionality or marketing your services. Today, teams still spend much of their day speaking to frustrated customers who either cannot find the information they need or have a common query about an element of the process that could be automated. This noise can be removed, helping both you and your customers.

Information out:

A hot topic in automation is the dissemination of reference data. Internal developers try to automate these processes through a few lines of code to fire out an automated email, which then joins a patchwork of other bits of code. Should that process change, however, amending that web of code is not easy and if the person who wrote that code then leaves, it quickly becomes near impossible to maintain. Even if this internal element of the process is somewhat automated, it still leaves a manual step on the receiving (customer) side.

Rather than customers receiving a .csv file over email or download link which – let’s face it – they probably won’t look at, wouldn’t it be easier to expose this in a Developer Hub or provide it on-demand as a REST API? Without a self-service interface where customers can self-select distribution streams and consume reference data, there remains a significant manual effort for both the customer and the internal teams. A portal allows customers to navigate instrument lists and trading hours on their schedule and in a more ergonomic format than a spreadsheet attachment. It allows the data to be dynamic, searchable and even bespoke depending on the individual or firm that is logged in.

Information in:

An element of onboarding and customer management that will require significant input from the connecting customer is getting their individual information in. Examples might include ordering up network connectivity, selecting comp IDs or inputting functionality requests or trading preferences. Customers are often required to manually fill out and return Word or Excel forms, which then need to be manually input into a system by the onboarding team.

Through a portal, customers can complete these forms online (not via PDFs!), with the data fed straight into a series of internal workflows without your teams having to process the information. Using the common example of network connectivity, data collection is automated and we remove the wait time associated with processing the information by triggering the next step automatically. Again, this makes the customer experience much less painful and significantly faster.

Where to start?

You will be forgiven if your first reaction to this article was “Wow, that feels like a lot of work!” And yes the up front implementation effort can be significant….but we can help with this and the end result is well worth it. There is also a danger of boiling the ocean by continually adding features and requirements until the whole project crumbles under its own weight. You cannot expect to move from fully manual to fully automated overnight; this has to be an iterative process.

A good starting point therefore is to list out the most manual and repetitive elements of the onboarding process and go from there. You will probably find that although elements of these workflows are indeed automated, the breakdown will usually be found in a manual interaction between you and your customer.

A Developer Hub can fix this. So what are you waiting for?