Running a connectivity desk in an investment bank or trading venue is hard. There is always too much to handle and the ever-present budget constraints demanding that you “do more with less” or make it work with what you can beg, borrow or steal.

Part of the challenge is that connectivity desks rarely have the luxury of focusing exclusively on the task of onboarding customers. Often the role is merged with other functions, such as:

  • Elements of production support, typically troubleshooting production FIX issues
  • Aspects of QA testing (you need to send in FIX messages to test your system right?)
  • Project management of the broader onboarding lifecycle, including management of external network providers or vendors
  • IT change projects such as migrating between vendor systems or providers

And while business management will always agree that production takes higher priority than customer onboarding, it doesn’t stop them from asking for fixed live dates for all customers with the expectation that targets are hit even if other, higher-priority issues crop up. And so there’s typically a chunk of management reporting involved in the role as well.

As we’ve highlighted throughout this series, the principal ambition of greater efficiency is achieved through better organisation and establishing clear, repeatable and measurable processes. Connectivity teams with even modest activity should use a tracking tool to assist with both the tracking of day-to-day tasks, task allocation across the team, and tracking progress. But what tools fit this purpose?

  • If we were talking here about a Sales team, then the recommendation would be to invest in a Customer Relationship Management (CRM) tool such as
  • If we were talking about a development team, the recommendation would be for a development ticketing tool such as Atlassian’s JIRA.
  • If we were talking about production support, we would recommend JIRA Service Desk or ZenDesk or one other the other myriad of tracking tools available on the market.
  • If we were talking about marketing, we would recommend inbound-marketing tools such as HubSpot.
  • … But what about connectivity teams?

The simple answer is that there are a minimal set of options that can handle the diverse range of activities and requirements of a connectivity desk. Choosing between them will come down to an understanding of your needs for such a tool. Before we delve into suggestions and recommendations, here are some of the top-of-mind questions we would consider when shopping for tooling:

Factors influencing your requirement definition:

  1. How many team members are there, and do they all need access at all times?
  2. How often does the team churn? Think about how often you are training new team members and how quickly you need them to be productive.
  3. Are they spread out geographically?
  4. What other responsibilities do they have? Think about production support or market supervision.

Factors for a successful implementation:

  1. Is the tool domain-relevant? If you find yourself trying to cram round pegs into square holes, then the tool isn’t it for purpose.
  2. Can it be customised to your requirements? Do you need to assign development resource to get to launch or for future changes?
  3. How easy is it for the team to learn and use?
  4. Does the pricing model scale correctly for your business? For example, are there variable fees which would balloon as your business grows?
  5. Will it satisfy both end users and managers? In particular, does management reporting come as standard?
  6. Will it help you move towards better processes and greater automation?
  7. How well does it integrate into other systems that you use internally?

So now we know what we are looking for, how well do the various options stack up?


Everybody has Excel, right? So why not create a spreadsheet to track this stuff, printing it off in advance of a weekly meeting?

Excel has the apparent advantage of being “free”, and sufficiently (infinitely?) flexible to allow you to track whatever you like in there. But if you’ve ever tried to run projects like this in the past, you will know that there is a vast difference between building a nice-looking progress tracking sheet and using it to organise work in practice.

Quite quickly, you will find that people forget to update the Excel, making it some poor soul’s job to collect updates and administer the spreadsheet in advance of each meeting. And if that person goes on holiday, or falls ill, or changes role… well then the process starts to crumble.

Excel also does nothing to automate workflows, nor does it actively help to improve processes. It is merely a way of tracking milestones in a process that remains mostly in users heads.

Conclusion: Excel is the obvious starting-point for firms who are just getting started with onboarding. You are likely to tire of the effort associated with maintenance though, meaning that you must move on quickly to avoid the process failing.

JIRA / JIRA Service Desk

JIRA is the most frequently-attempted option for firms who feel that they have out-grown Excel. The majority of development teams use this these days, and therefore it is almost certain that your firm has a license somewhere; so why not try modelling onboarding tasks (or projects) as JIRA tickets?

Talking to folks who have tried this route shows similar problems to How are multiple steps in an onboarding project represented in JIRA? Is each step an issue, and if so, how can we see the overall status of a project comprising of a series of tickets? And while JIRA is extremely helpful when assigning development tickets and managing them through a lifecycle within a development sprint, onboarding tasks often take a less direct route to completion and don’t fit in well with the idea of a time-bound sprint cycle.

Management reporting also comes back into consideration with JIRA; as the sales teams don’t have access to it, you are back to the chore of producing manual reports again. (JIRA has some reporting capabilities of course, but it is ill-suited to the production of sales-oriented dashboards, and in particular, it fails to anticipate live date).

Conclusion: JIRA is excellent for development, but not great for onboarding (or the other tasks the team do). Most attempts to use JIRA fail because it is difficult to customise, automation is hard, and management reporting is not very business friendly.

You may have a sales team who use to track their sales pipeline. It is a natural conclusion to suggest that this could be extended to track various stages of the post-sale onboarding process.

While this idea offers the promise of good management reporting and tight coupling with other internal databases (customers, contacts etc.), we have talked to many firms who have struggled to get any meaningful level of automation out of it. Indeed, the cost of the initial customisation was high, requiring specialised developer training. A number also report being “trapped” on a specific SalesForce version, awaiting the developer resources to upgrade them to newer versions… And this is even for quite simple, one-page SalesForce implementations.

The per-user fee structure of SalesForce also creates a potentially significant cost base if you need to add users for anybody involved in onboarding (including networking, etc.).

Conclusion: Much like JIRA, SalesForce is designed for a completely different workflow. While reporting is better, per-user pricing and the need for custom development make this an expensive and challenging option.

In-House Build

Frustrated by the lack of off-the-shelf tools, some firms have felt the need to try building something in-house. How the application came into being is often an entertaining story, which typically involves “borrowed developers” (or a colleague who writes scripts as a hobby) who were “working under the radar” to “do something quickly”.

In-house technology always occupies a strange place in firms we’ve found. Once an in-house application exists, it is likely to be far, far more “sticky” than vendor products. Perhaps this is because the in-house tool was moulded to their precise requirements, meaning that users don’t need to compromise or change their working practice in the same way that they may have to with vendor products. Perhaps they are sticky because of a sense of ownership pride that is absent for vendor-supplied tools.

The near-universal experience of firms with such in-house tools is that the functionality remains rudimentary and that they are inflexible to change once the initial developer has left or become too busy to maintain it. Unfortunately, this means that such firms typically limp along with half a product while they wait for something better to come along, or for developer resources to free up to make new changes.

Conclusion: A historic choice for firms which have tried (and failed) with options such as JIRA, and who had the luxury of excess development capacity. While there is no license cost to budget for, the real cost of building and maintaining tools like this is exceptionally high, and the functionality delivered rarely shines.

FixSpec Flow

After understanding the various drawbacks of options presented above, FixSpec recently developed Flow – a new workflow tracking and automation application designed to suit the needs of Connectivity teams.

Not only does Flow allow firms to design their onboarding workflows, forms and email templates (and change them over time without the need for a developer), it can track and automate each project, releasing the next task at precisely the right time.

At launch, Flow will integrate with other tools in the FixSpec stack to automate elements of the certification process, and we aim to release SalesForce and JIRA webhook integrations shortly after that.

Conclusion: We have designed Flow to suit what we understand as the market need perfectly… but then we are biased! Why not drop us a line or message us at @FixSpec to organise a demo and see for yourself?