PrimaryBid Connect - A data transfer story

Introduction

Currently, all UK ECP orders are submitted via email and must be manually keyed in by the Operation team. This creates operational uplift for both sides involved and limits PrimaryBid’s ability to expand relationship with partners by granting them control of and access to informations.

Historically, in order to solve this PrimaryBid have been developing a self-serve broker portal to accomodate partner needs. This has not yet been launched due to three main points:

• Feedback from partners requiring more features,

• Over-delivery of scope items,

• Shift in company priorities leading to unfinished engineering tasks.

This project has been resurrected in November 2021 due to growing activity around 3P order processing, the potential this has for improved partner relationship management and also for internal plans of expansion.

What problem the Brokers are facing?

During an IPO, all partners in uk manually provide subscriptions to PrimaryBid.
Partners are not typically involved in community offers because the manual work required is very high, creating a barrier given how short the timelines for these offers are.

All partners in uk are currently utilising our customer operation team, the order arrive via email and even Whatsapp. In cases where we have a CSV/Excell files, there is a lack of standardisation in these files.

What are broker workflow?

Within a brokerage firm, the teams are composed of a team lead and then individual brokers. The individual brokers are taking orders from retail customers via phone call and Whatsapp. For the IPO offerings the order is booked in their own system which allocates funds since shares do not exist in their order management system.

These individual brokers notify their team lead of the orders they have placed , then the team lead consolidates these and send us the orders.

PrimaryBid receive the orders in two ways:

1. Line by line

2. Aggregate (this method create some issues because it will hide individual investor demand and PrimaryBid will not be able to allocate to that investor)

For the aggregated orders, the justification being surfaced from brokers during the interview are that they:

• Need to follow an internal manual process related to risk which require aggregation,

• Do not want to share customer informations,

• Want to allocate back to their customers based on their own rules

Another issue is that Brokers have legacy system which means its difficult for them to introduce changes into their workflow.

The challenge

International expansion, marketing and commercial teams do not have enough product capabilities to start deepening relationships with partners. This limits PrimaryBid’s ability to gauge demand and estimate deal pipeline in international market ahead of launch.

Manual order submission is a high risk, laborious manual approach which is prone to human error. Brokers submit orders shortly before the deal close, this results in actions being carried out with urgency and may resulting in errors.

Development and design process

I started my design process reading all the documentations collected from PM and Stakeholders. Then followed the double diamond design flow: DISCOVER, DEFINE, DEVELOP, DELIVER.

Research process

The research process was carried out from the UXR team I was collaborate with, and the structure utilised was the following:Open ended questions to learn about their routines, tools workflow and internal processes, roles and responsibilities,Jobs to be done ranking,Sharing a working prototype and get them to submit an order (talk out loud technique)

Paper prototype

To start concretise all the informations collected in the previous stages I started jotting down some very low fidelity sketches of the page’s content to have a rough base to then build the hi fidelity design.

Iterations

First iteration

An original high-fidelity design for the home page, after the login the Broker will find this page from where will be able to take different actions.

Second iteration

First high fidelity design straight from the paper sketch. The informations for the deals are housed in a table style view, a quite common way to showcase informations in finance, but not very accessible from mobile smartphone or tablet.

Third iteration

On this iteration we changed the approach to the informations, instead of using a table style view (difficult to make accessible on mobile) we opted for a card view system, where every offer is housed inside a card, making it easy for the responsive layout and accessible on mobile.

Fourth iteration

On this last iteration we opted for a two column layout, easy to navigate and to access from all devices.
Each card now have two cta, one to apply directly and one to visualise more offer details.

The page navigation has been simplified as well, with a first level navigation: Offers and Applications, and a second level navigation with Live and Closed offers.

The product has also been renamed from PrimaryBid Broker to PrimaryBid Connect.