A pilot is a small version of a rollout. It picks a slice of the book, changes how a team works on that slice, and asks the team to report back. Pilots fail for reasons that have nothing to do with the tool: the slice is unrepresentative, the team is busy, the change is disruptive, and after three months everyone has an opinion and nobody has a comparison.
For a monitoring tool there is a better design, and it is the one we now ask every prospective client to run. Do not change anything. Run ExactCov in parallel.
Same inputs, independent output
The parallel run works like this. The agreements for the funds in scope are loaded once. The NAV notices that already arrive by email are copied to a mailbox we watch, or we pull them from the same portal your team uses. That is the entire integration. Nobody stops using the spreadsheet. Nobody learns a new screen unless they want to. The register runs on its own, every day, against exactly the data the team is already processing.
After four weeks you sit down with two outputs: the team's book as they reported it, and ours. You compare them on the questions that matter.
- Which funds did we mark stale, and did the team know?
- Which deliverables were late, and were they chased?
- Where did the tests disagree, and which basis explains the disagreement?
- Which limits should have moved, and by how much?
- What did the register find that the book did not: a missing deliverable on an umbrella fund, a floor that should have re-based, a cross-default nobody had linked?
Every disagreement has a citation on our side, so the comparison takes an afternoon, not a project. If our number is wrong, you will see why on the page. If the book's number is wrong, so will they.
A pilot asks a team whether they liked the tool. A parallel run asks the book whether it was right.
Why four weeks is enough
One monthly cycle is enough to see every failure mode once: the NAV that arrives late, the one that arrives as an estimate, the fund that reports nothing, the notice that leads with the wrong NAV. Four weeks also means the run finishes before anyone has to defend a budget line for it. If the comparison is not decisive, you have lost a mailbox rule.
The commercial logic
The parallel run leads naturally to how we price, because the two are the same argument. A monitoring tool exists to widen coverage. It should therefore never punish you for widening it.
Per-seat pricing does exactly that: the moment a second desk wants to see the register, the cost goes up, so it stays with one team and the coverage stays narrow. Per-project pricing does it differently: the book gets monitored in slices, on whatever timetable the budget allows, and the slices in between are exactly where the stale funds live.
ExactCov is priced per fund in scope, with a floor. Every user in the bank who should see the register sees it. Every agreement, notice and test for a fund is included. The floor covers the smallest useful book, so a team can start with the funds it is most worried about and add the rest as the parallel run makes the case. The price of monitoring a fund is a fraction of the price of one missed trigger on it, and it is a number you can put in a spreadsheet, which we appreciate the irony of.
If you have read this far after a first call with us, this is the post to forward. It says what we would ask you to do, what it would cost you to find out, and what it would cost afterwards. Everything else is on the page, with a citation.