A partner evaluating a sell-side platform should check six things: phase coverage, data traceability, buyer data quality, confidentiality terms, pricing model, and what the owner sees. Each can be verified in a demo or a contract, and a platform that fails any one of them may cost the bank more than it saves. The checklist is deliberately short because the partner running it is also running three mandates, and a forty-item evaluation matrix will be delegated to an associate who does not know which items matter.
Phase coverage: does it run the whole process or one step
The first check is the simplest. List the six phases of a sell-side engagement: discovery and readiness, valuation, marketing materials, buyer matching and outreach, offers, and negotiation through close. For each, ask whether the platform holds the work or whether the work leaves the platform for another tool.
A platform that covers two phases is a point solution with a bigger brochure. It may be excellent at those two, and it will create a seam at each boundary where the bank's data has to be moved by hand. The partner should know going in how many seams remain, because each is a cost the platform's price does not include.
Ask specifically about the transitions. Does the valuation feed the CIM, or is the valuation exported and the CIM built elsewhere. Does the buyer list become the outreach tracker, or is it exported to a spreadsheet. Does an executed NDA grant data room access, or does someone create the user by hand. The answers reveal whether "end to end" means one record or six tabs.
A platform does not need to cover negotiation and close with any depth. That phase belongs to the banker, and software's role there is organizing terms and timelines. But it should hold the LOI and exclusivity dates in the same place as the IOIs they came from.
Data traceability: can every number be followed to its source
The second check matters more than it sounds. Ask the vendor to show a valuation output and then show where each input came from. Then ask to change one input and see whether the output changes predictably, and whether running the same inputs twice gives the same result. NIST treats documented validation, transparency, and provenance as important parts of trustworthy AI systems, which is a useful standard for this demo test. [1]
A valuation engine that produces different numbers for the same inputs on different days is not a tool the bank can present to an owner. The owner will ask how the number was reached, and "the model produced it" is not an answer a banker can give. The engine should be deterministic, and every figure should trace to its source, so the associate reviewing the output can confirm each one.
The same test applies to generated documents. Ask to see a CIM draft and then ask where the adjusted EBITDA figure in the executive summary came from. If the answer is a specific questionnaire answer or data room file, the platform supports the bank's review rule. If the answer is that the model inferred it, the platform has created review work rather than removed it.
Buyer data quality: recency and closed deals, not directory size
The third check is about the buyer database, and the question is not how big it is. Every vendor will quote a large number. The question is what each entry represents.
Ask three things. Is each buyer included because it has actually closed an acquisition, and how recently. A directory of firms that describe themselves as acquisitive is different from a list of firms that have written a check. Two years is a reasonable window to test; a buyer that closed something five years ago may have changed strategy, leadership, or fund status since. How is the database maintained, and how often are entries added or removed. A list that was accurate at launch and never refreshed degrades monthly. Does the database cover the buyer types the bank's mandates attract. A lower-middle-market industrial business draws a different buyer pool than a software company, and the bank should ask to see the fit for its actual verticals.
Then ask how the bank's own relationships fit in. Every boutique has a list of buyers the partners know personally, and those relationships are the firm's edge. The platform should let the bank add those buyers, tag them, and combine them with documented acquisition criteria, not force a choice between the two.
A useful test in the demo: describe the bank's most recent closed mandate and ask the platform to build a prospect list. Compare it to the list the bank actually used. Overlap is good. Buyers the bank missed are better, if they are plausible.
Confidentiality terms: the contract, not the security page
The fourth check is the one the partner cannot delegate. Before the platform sees any client content, the contract should state how the bank's uploaded content and generated output are handled, how client data is isolated from other customers, whether it is used to train models serving anyone else, which subprocessors are involved, and how content is deleted on request. Written safeguards and service-provider controls are central themes in financial-information rules, but applicability depends on the firm's status and the engagement, so counsel should review the actual terms. [2]
Read the data processing addendum rather than the marketing page. Ask who at the vendor can access client content and whether that access is logged. Ask whether the platform supports role-based access within the bank, so an analyst can be limited to the mandates she is staffed on.
If the vendor's answer to any of these is a reassurance rather than a contract clause, the platform fails this check regardless of how it performed on the first three. The bank's duty of confidentiality to the owner does not have an exception for good software.
Pricing model: what happens to cost when mandates grow
The fifth check is the pricing structure, and the question is what the bill looks like when the bank runs twice as many mandates with the same team.
Per-deal pricing means every mandate adds cost, which is tolerable for a bank running two and punishing for a bank running ten. It also creates an awkward incentive to under-invest in tooling on a smaller mandate. Per-seat pricing on a flat monthly subscription means the bill is a function of headcount, and the incremental mandate adds nothing on the tool side. For a bank whose strategy is more mandates per banker, per-seat is the model that matches the strategy.
Ask whether one seat can run multiple concurrent processes. If each mandate needs its own seat, "per seat" is per deal in a different costume. Ask what happens to pricing at renewal, and whether there are charges for data room storage, buyer list exports, or document generation that sit outside the headline price.
What the owner sees: the client-facing test
The sixth check is one partners often skip because they are evaluating the tool for themselves. Ask what the owner's experience is.
The owner is the bank's client and its referral source. If the platform's client-facing side is a stream of emails from different associates, the owner's experience has not changed. If it is a branded portal where requests appear, uploads happen once, and the owner can see what has been asked and what has been provided, the owner has a reason to describe the bank as organized to the next owner who asks.
Ask to see the portal from the owner's side in the demo. Ask whether it carries the bank's branding or the vendor's. Ask what the owner sees when a request is outstanding and what happens when the owner uploads a revised document: does the revision flow to the valuation and the CIM, or does an associate have to notice?
A practical step for this week: before any demo, write the six checks on one page with space for notes, and bring it. The demo will follow the vendor's script; the page keeps the partner on the bank's questions.
How Acquivo Pro fits
Acquivo Pro is built to address this checklist. It covers the six phases on one login, from discovery through valuation, teasers and CIMs, buyer matching, and NDA, IOI, and LOI flow. The valuation engine is deterministic and figures trace to their source. Buyer matching uses documented acquisition criteria rather than a verified published total of buyers. Client data is isolated and not used to train models for other customers. Pricing is per seat on a flat monthly subscription with no per-deal fees, and one seat runs multiple concurrent processes. The owner sees a branded document portal where uploads happen once. To see it on a live mandate, request a demo through the Contact page.
Key Points
- A partner evaluating a sell-side platform should check six things: phase coverage, data traceability, buyer data quality, confidentiality terms, pricing model, and the owner's experience.
- A sell-side platform that covers two of the six phases is a point solution that leaves the bank's data to be moved by hand across the remaining boundaries.
- A valuation engine the bank presents to an owner should be deterministic, producing the same output from the same inputs, with every figure traceable to its source.
- A buyer database should be judged by whether its entries have documented acquisition criteria and recent evidence, not by how many names it contains.
- Per-seat pricing with no per-deal fees is the model that matches a boutique bank's strategy of running more mandates with the same team.
Sources and references
Source retrieval dates record research access, not article publication. Read our editorial and date policy.
Choose your next step
Acquivo is user-operated software. Owners and their professionals remain responsible for decisions, communications, and professional review.
Educational information, not individual legal, tax, or investment advice. Consult qualified professionals for your circumstances. Acquivo provides software, not representation or negotiation on your behalf.