Arbitration and Hearing Management Software Problems: The 6 That Cost Real Money, and How to Avoid Them

Why does the bundle and reference scope get underestimated so often?

Proposals in this category describe document management and search, which sounds like a repository. The actual requirement is a compiler. A bundle is a compiled view over an ordered set of documents, with deterministic pagination, a generated index and a reference graph that survives recompilation.

What gets missed is that references live inside other documents. Pleadings, witness statements and expert reports all cite exhibits, and those citations were written by humans in prose, in several formats, over months. Capturing them as links to a stable identifier rather than to a page number is the work, and it is part extraction, part convention, part human review. It cannot be added later, because the display layer has to resolve references at render time and the storage model has to hold them as objects rather than as text.

The fix is a design decision taken in the first conversation and tested with a question. Ask how a reference to exhibit C-142 page 7 stays correct after the bundle is recompiled with nine new documents inserted. If a page number is stored anywhere as identity, you will repaginate overnight exactly as you do now, and you will have paid for the privilege. The right answer separates a stable exhibit identifier and internal pagination from the compiled bundle position, and produces a printed concordance for anyone working from paper.

What goes wrong when you migrate historical case files and exhibits?

Three problems, and they compound.

The first is that historical bundles exist as flattened documents. A prior hearing bundle is often a single large file with a burned in pagination stamp, so the individual exhibits have to be split out again and the split is not reliably obvious. Optical character recognition helps and does not solve it, because a stamp can be misread and an exhibit boundary can fall mid page.

The second is provenance. In a matter that ran for four years, the same document may exist in five versions across disclosure, with different redactions applied for different purposes. Migrating them as separate documents without recording the relationship produces a repository where a search returns five near identical results and nobody can say which one was before the tribunal.

The third is confidentiality state. A document that sat inside a confidentiality ring during a prior phase carries obligations that outlive the phase. If the migration loads everything at a single access level, you have created an exposure on day one.

What works: migrate live matters only, exhibit by exhibit, with the case team confirming boundaries and confidentiality state as part of the exercise rather than afterwards. Load closed matters as archival records at their original access level, searchable but not compiled. Record redaction lineage explicitly so a redacted version is visibly derived from an original rather than sitting beside it as a sibling.

Why do the transcript, video and document feeds break after launch?

The live transcript is the feed that matters most and it is the least standardised. Stenography feed formats vary by provider and by market, and the provider is chosen per hearing, sometimes late, sometimes by the other side. A system built against one provider's format meets a different one in month four.

The second break is the rough to final transition. During the day the transcript arrives as a rough version. Overnight it is corrected and replaces what was there. Any note, mark or link made against the rough version has to survive that replacement, and systems that store raw character offsets lose them all. Resilient anchoring is not a refinement, it is the difference between counsel trusting the tool during closings and abandoning it on day two.

The third is remote hearing video, where the platform is chosen by the tribunal or the venue rather than by you, and synchronisation between recording and transcript anchors depends on clocks that drift.

What prevents most of it: treat the transcript feed as an adapter boundary with a canonical internal format, so a new stenography provider is a mapping rather than a rebuild. Ask any prospective developer which providers they have ingested by name. Anchor annotations to content rather than to offsets. And confirm the video platform per matter at the procedural conference, not in the week before the hearing.

What happens when confidentiality rings and data residency are not covered?

These are the two requirements most often deferred, and both are expensive to retrofit.

Access in a hearing is a matrix, not a hierarchy. The tribunal sees the full record and its own private annotations. Each party sees the common record plus its own work product. Experts see their instructions and material within their remit. A tribunal secretary may organise and draft without holding a decision making footprint. In competition and trade secret disputes some documents are visible to external counsel and not to the client, and ring membership changes as the case develops.

If that is enforced in the interface rather than at the data layer, it leaks through a side channel: search results that reveal the existence of a document, an export that includes another party's annotation layer, a print view that ignores the rule. Those are the leaks that actually happen, and they are not recoverable.

Data residency is the other one. Parties or the seat may require the record to remain in a specific jurisdiction, and in some arbitrations that requirement is not negotiable. It has to be a design assumption, meaning the ability to deploy into multiple regions and pin an individual case to one, with backups and logs respecting the same boundary. Retrofitting it usually means rebuilding storage and access layers, so raise it in the first design conversation even if no current matter needs it.

Should you build custom or configure what you already own?

If you run occasional domestic arbitrations, or a handful of hearings a year with conventional bundling, license a hearing platform per case and stop. Opus 2 is genuinely strong on hearings and transcripts and is used in large international matters for good reason. Thomson Reuters Case Center is strong at electronic bundling and widely used in court settings. The per case cost is modest against the exposure, and building your own would be an indulgence. We give that advice regularly and it costs us projects.

Before assuming a build, run one test. Take your own exhibit numbering and pagination conventions to the vendor and ask them to demonstrate a full compile and recompile with a late insertion, using your conventions rather than theirs. If it works, your problem was configuration rather than product fit. If the answer is that you should adopt their convention, you have measured the constraint, and whether that constraint matters depends on whether your conventions are institutional or merely habitual.

Build when volume and specificity appear together. Either alone points to licensing. Together, which usually means an institution whose appointments, deposits, tribunal fee accounts and rule based timetables live in spreadsheets alongside a licensed hearing tool, or a disputes practice running several very large hearings a year with residency requirements a vendor's hosting cannot satisfy, the case is real.

How do hidden costs get into an arbitration software quote?

Five places, and they are specific to this category.

• Data residency. Deploying into multiple jurisdictions with per case placement is an infrastructure exercise, not a setting, and it multiplies the operations work rather than adding to it.
• Character recognition and translation volume. International matters carry documents in several languages and scripts, and quality varies enormously with source condition. Priced per page it looks small and at scale it is not.
• Transcript providers. Each stenography feed format is an adapter. A quote priced against the provider you used last year meets a different one when the tribunal appoints.
• Institutional rule variation. If you administer more than one set of rules, timetables, appointments and fee logic differ per rule set, and that is logic rather than configuration.
• Offline hearing mode. Local caching, offline annotation and reconciliation on reconnect is real engineering and is routinely omitted from first quotes.

What keeps the number down is scoping release one to the bundle compiler, the reference graph, search and party segregated access. That is the part that fails at eleven at night.

What separates a hearing build that works from one that fails?

Working systems survive the hearing room network. Rooms in arbitration centres and hotels have unreliable connectivity, and a platform that stalls will be abandoned by mid morning on day one in favour of paper and a laptop full of files. That means the bundle cached locally, annotation available offline and reconciled on reconnect, and a presentation mode that never waits on the network to display a document. This is not a refinement to add in phase two, because there is no phase two for a tool the team stopped trusting on the first morning.

Working systems also treat the tribunal as a distinct user with distinct needs rather than as another party account. A tribunal member wants to move quickly between a transcript line, the exhibit it refers to and their own private note, with nothing on screen that belongs to a party. Getting that wrong is not a usability complaint, it is the reason a tribunal reverts to paper and the parties follow.

Failing builds usually delivered a good repository and lost the hearing. They indexed everything, searched well, and had no compiler, so bundle production stayed a manual exercise and the eleven at night problem was untouched. Test any design against one scenario before committing: nine exhibits inserted the evening before day one. If the answer to that scenario is a recompile and a printed concordance, the design is right. If it is a team of paralegals, you are buying a search engine.