How to Evaluate a Capital Markets CRM (Sell-Side)

Evaluating a capital markets CRM comes down to eight questions, and none of them are about features. Feature lists across sell-side vendors converge — everyone has interaction capture, everyone has readership, everyone has a corporate access module. What separates the systems is the layer underneath: what arrives automatically, how fast, how it is joined, and what happens when the firm asks it a question it was not configured for in advance.

This guide is for the person running the selection — a COO in global markets, a head of front office technology, a CRM product owner, or the research or sales leader who will live with the outcome. It assumes you already know what a capital markets CRM is and why a horizontal platform struggles on a sell-side desk.

Why this evaluation works differently

Most enterprise software evaluations score features against a requirements matrix. That method fails here for a specific reason: on a sell-side desk, the requirements that matter are properties of the data, and data properties do not demonstrate well. A demo environment has clean, complete, current data by construction. Every product looks like it has a single client record when the record was assembled by hand the night before.

So the questions below ask for evidence. Several require the vendor to demonstrate something live, on data they did not prepare. That is the whole method.

The eight questions

1. What arrives automatically, and with what lag?

Go through the list one source at a time — research readership, emails, calendar meetings, chat, call logs, corporate access sessions, conference attendance, trading flow, holdings, commission data — and ask two things about each: does it land without a human typing it, and how old is it when it lands.

The answers will vary by source, and they should. What you are listening for is whether the vendor knows the numbers. A vendor who has deployed this at firms like yours can tell you that flow lands intraday, readership within the hour, and holdings after the filing cycle. A vendor who answers “in real time” across every source has not thought about it, and you will find out which sources are nightly batch jobs during implementation.

Ask specifically what happens on the sources you care about most. If pre-call preparation is the use case, the readership and flow latencies are the product.

2. Who resolves the client entity?

The same institution appears under a different identifier in the entitlement platform, the order management system, the market data feed and the existing CRM. Somebody has to decide those are the same client, keep deciding it as funds are added and mandates move, and handle the cases where the answer is ambiguous.

Ask who owns that. If entity resolution is delivered as a mapping table the firm maintains, the integration cost lands on a team that already has a backlog. Ask to see what happens when a new fund appears in one source and is missing from the others.

3. Can the broker vote be reconstructed?

Pick a client. Ask the system to show every input behind that client’s commission allocation over the past year — research consumed, meetings taken, corporate access attended, calls, the analysts involved, and how each was weighted.

This is the single most revealing request in the evaluation, because it exercises capture, joining, history and reporting at once. If reconstructing it takes a services engagement, then attribution at that firm is a spreadsheet exercise with a CRM attached, and the vote will keep being negotiated on anecdote.

4. How is coverage modelled across desks?

One client is covered simultaneously by a research analyst, a salesperson and a sales trader, and may be in a banking dialogue that neither of the others can see. Each has a different view of the relationship and a different claim on it.

Ask whether that is native to the data model or handled by convention. Systems that flatten to a single owner per account push the real structure into naming schemes and shared spreadsheets, which works until someone leaves.

5. What does real adoption look like?

Adoption means daily active users. Ask for that figure as a percentage of licensed front-office users, at a named comparable firm, measured across a full quarter well after launch.

Then ask the harder question: what drove it. Adoption on a trading floor follows from the system already knowing things when a user opens it. If the answer is training and mandates, the number will decay, and you can ask for the twelve-month figure to test that.

6. How are information barriers enforced?

A platform serving both the private and public sides has to separate them structurally. Ask where that separation lives — in the data model and the query layer, or in field-level visibility settings on top of a shared record.

Ask what the audit trail looks like, who can grant an exception, and what compliance sees. This question tends to sort vendors quickly, because the firms that have deployed at full-service banks have been made to answer it before.

7. What is the total cost beyond the licence?

Licence, implementation, and then the tail that gets left out of business cases: connector development, ongoing integration maintenance, the reconciliation work that continues after go-live, data quality remediation, and the internal headcount that ends up owning all of it.

Ask what a new data source costs to add in year two — as money and as elapsed weeks. Ask how many of the connectors you need are existing products versus builds. The gap between vendors on total cost is usually much wider than the gap on licence, and it runs the other way about as often as not.

8. Who can change things without calling the vendor?

Coverage models change, desks reorganise, new products get added. Ask which changes an internal administrator can make, which need vendor services, and what the turnaround is on the second category.

A system that requires a services ticket for routine change will be configured correctly on day one and slightly wrong for the following three years.

What to ask the vendor to demonstrate

Three requests that surface more than any scripted demo:

Run it against a client you name. Ask to see a real record in the vendor’s reference environment, with the client chosen by you.

Show the same client from three seats. Research, sales, sales trading. Watch whether it is the same underlying record with different views, or three screens that agree because someone made them agree.

Ask what happens when a source is unavailable. How does the record present when the entitlement feed fails overnight? A system that shows stale data indistinguishable from current data is a system that will be trusted at exactly the wrong moment.

Reference call questions

References are pre-selected to be positive, so use them for texture:

• How long between contract and the first desk using it daily?
• What did you have to build yourselves that you expected to be included?
• Which desk adopted slowest, and why?
• What have you asked for that the vendor could not do?
• If you ran the selection again, what would you weight differently?

The last question produces the most useful answer, because it is the one people have actually thought about.

How to weight the criteria

Weighting depends on the wedge. A firm whose pain is pre-call preparation should weight questions 1 and 2 most heavily, because the entire value is a current, joined record. A firm whose pain is the broker vote should weight 3. A full-service bank with an active banking franchise cannot treat 6 as a checkbox.

What should not happen is even weighting across a long matrix. It produces a winner that is nobody’s first choice and satisfies the requirement nobody was actually feeling.

Where these evaluations usually go wrong

Scoring the demo. The demo environment is curated. Score the answers to questions 1 through 3.

Treating a configuration project as a purpose-built system. A horizontal CRM with a sell-side accelerator can be made to look right in weeks. What cannot be configured is what the platform ingests, how often, and what it can join.

Deferring the integration question. “We will connect that later” is an architecture decision presented as a sequencing decision, and the later arrives partially.

Letting the vendor set the reference list only. Ask for a firm that churned, or one where the rollout was difficult. The response to the request is informative even when it is declined.

Frequently asked questions

What should be in a sell-side CRM RFP? The eight areas above, phrased as evidence requests. Ask for latency figures per data source, a live vote reconstruction, adoption measured as daily active users at a named comparable, and a total cost breakdown that includes connector development and ongoing reconciliation.

How long does a capital markets CRM evaluation take? Long enough to see the product against real data. Compressed timelines push firms toward scoring demos, which is the failure mode this guide exists to prevent.

Who should be in the room? The desks that will use it — research, institutional sales, sales trading, corporate access — plus front office technology and compliance. Compliance early rather than late, because question 6 can eliminate a vendor after everyone else has picked them.

What is the most common mistake? Evaluating the interface. The interface is the part that is easiest to change and the part every vendor has already optimised for the demo.

---

Datazoic is an AI native sell side product suite for Capital Markets, purpose built for front-office teams at investment banks — covering equity research, institutional sales, trading, corporate access and investment banking in a single client record.