Blog · Coverage and territory · Investment banking
How an investment bank's institutional sales desk measures coverage from its own revenue and contact data: which clients each salesperson reaches, which products each client trades with the desk, and the roll-up that reconciles to the benchmark submission.
An institutional sales desk knows its revenue by client. It knows, informally, who covers whom. What it rarely has is one view that says, for every salesperson, which clients they reached this quarter, which products those clients trade with the desk, and how that compares to the benchmark the bank already submits. This guide sets out how to build that view from the desk's own data.
Client coverage: of the clients assigned to a salesperson, how many were contacted or traded in the period.
Client coverage = clients with a trade or logged contact ÷ clients assigned
Product coverage: of the desk's products, how many each client trades with the desk.
Product coverage = products traded by the client ÷ products the desk offers to that client type
The first tells the head of desk where salespeople are thin. The second tells them where clients are thin. A desk can score well on one and badly on the other, and the fix is different in each case.
Client identifiers throughout. The desk's own client codes are enough; the benchmark provider already uses them.
The final assertion is the one that makes the number bankable:
desk revenue = Σ regions = Σ salespeople = Σ clients = benchmark submission
When it holds, every figure on every screen agrees with what the bank told the provider. When it does not, the report says at which level, and usually why: a client under two salespeople after a reorganisation, or a sub-product mapped to the wrong product.
A desk covering Japan, Asia North and Australia, one product family, one quarter. Figures in millions.
| Salesperson | Region | Clients assigned | Clients traded | Client coverage | Revenue |
|---|---|---|---|---|---|
| SP004 | Japan | 18 | 15 | 83% | 3.92 |
| SP001 | Japan | 14 | 9 | 64% | 2.71 |
| SP002 | Asia North | 22 | 19 | 86% | 2.14 |
| SP005 | Australia | 11 | 11 | 100% | 1.10 |
Region totals: Japan 6.63, Asia North 2.14, Australia 1.10. Desk 9.87. The benchmark submission for the quarter says 9.87. Reconciled.
SP001 is the finding: five assigned clients with no trade this quarter. The product view adds the second finding: of SP004's fifteen traded clients, six trade one sub-product only, and the benchmark file says four of those six have a wallet in the sub-products they do not trade. That is the desk's Monday list, and it took no new data.
Sub-products mapped inconsistently. The revenue ledger names a sub-product one way and the benchmark file another. Keep a mapping table from every code in every source to one product hierarchy, and apply it before the roll-up.
Joint coverage. Two salespeople on one client, which is common on large accounts, double the client in the salesperson roll-up. Decide the primary owner for reporting, keep the secondary as an attribute, and assert that salespeople sum to the desk.
Contact without a client code. CRM entries logged against a contact's name rather than the client entity never join to revenue. The contact log needs the client identifier on every row, and the report should count the rows without one.
Period boundaries. The benchmark submission is quarterly; the CRM export is whatever was pulled. Cut both at the same date, and say which.
Mapped once, the same exports produce the same roll-up every quarter, reconciled to the submission, with each salesperson's clients and each client's products ranked by the gap. On an enterprise deployment this runs inside the bank's own tenant with client identifiers only, and the benchmark file joins on the same identifiers. The investment banking page describes the setup, and the validation report is what the desk sees first.
Coverage asks whether a client was reached and which products they trade with you. Wallet share asks what proportion of the client's spend in a product you hold. A client can be fully covered and give you a small share, or lightly covered and give you most of what they do. Both numbers are needed and they are computed from different data.
The bank already submits revenue by client and product to a benchmark provider. That submission is the reconciliation target: the desk's roll-up must equal it, to the penny, for the same period. Once it does, the provider's wallet estimates per client can be joined on the same client identifiers.
Yes. Every measure works on client identifiers. The name mapping stays in the bank's systems, and on an enterprise deployment the whole roll-up runs inside the bank's own tenant.