How a ten-person deal firm should start with AI

The first step costs nothing: list the recurring work and put rough hours against it. Buyer research and list building. Teaser and IM assembly. Data room review. Call notes and follow-ups. Pipeline reporting. Ask each person which task they would give away first, and how many hours it takes in a normal week. The answers cluster fast.

This inventory does more than rank opportunities. It sets the unit of success before any vendor is in the room: hours returned to the firm. A system judged on hours is easy to evaluate and hard to oversell, which is exactly the framing a buyer wants.

Before asking what AI can do, decide how client material may be handled. Agree the processing purpose, hosting, providers, access and retention before selecting a model. Deployment within your own environment can be appropriate for some firms; managed infrastructure can be appropriate for others. The arrangement needs to fit the confidentiality requirements of the engagement.

Deciding early has a filtering effect: a whole category of consumer tools and pooled platforms drops out before anyone wastes a pilot on them. It also means that when a client or their lawyers ask where their information went, the answer already exists.

Resist the platform instinct. Take the single workflow at the top of the inventory, usually document assembly or document review in some form, and build the narrow version: grounded in your templates and your files, producing drafts a named person reviews, connected to the tools the firm already uses. Working software within weeks, used on live mandates while it is refined.

One finished workflow beats five pilots for a reason that has nothing to do with technology: it settles the trust question. The team learns where the system is reliable and where the checkpoint sits, on real work. The second workflow is then easy to choose, because the first one produced evidence instead of opinions. That evidence also makes the second build cheaper. The connections, the permissions and the review habit are already in place, so the next workflow starts from a working foundation rather than from nothing.

Nothing in the first system should decide anything. It drafts, extracts, sorts and summarises; the people who currently exercise judgement keep exercising it. This is partly about safety, since a plausible wrong number reaching a client costs more than the system saves, and partly about adoption: a team that is being assisted cooperates with a rollout, and a team that suspects it is being replaced quietly starves it.

In a firm of ten, adoption is not a programme, it is a handful of individual decisions to keep using the thing. Design for those decisions: the system should meet people inside the tools they already work in and remove a task they already resent.

Review the system against the original number: hours returned, on the workflow it was built for. Short cycles suit this, a few weeks at a time, because the first version will be wrong in small ways only live use exposes: a template quirk, a document type nobody mentioned, an exception that needs a home. The measure of the system is not that these appear; it is how quickly they get fixed.

This is also why the maintenance arrangement matters more than the build. Models change, terms change and the firm's own process drifts. Whoever builds the first workflow should expect to still be adjusting it a year later, and a firm should be suspicious of any proposal that ends at handover. Judged this way the decision to continue is simple. If the hours returned are visible to the partners each cycle the arrangement is working, and if they are not it should stop.

In most small deal firms the inventory points at document assembly or document review. Teasers, buyer profiles and Information Memorandum drafts consume junior hours and senior review time every week, and the inputs already exist inside the firm: templates, prior documents and the source material for the company being sold. That combination, high hours and available inputs, is what makes a workflow a good first candidate.

Document review is the other common answer: pulling the terms that matter out of a stack of NDAs, or the key figures out of a data room, into a structured form a person can check quickly. Both workflows produce a draft with a checkable output, which is the property that keeps the first system safe while the team learns where it is reliable. Both also produce a result a partner can check in minutes rather than hours.

Very little, and none of it technical. The first call is about how the firm runs deals today and where the process breaks down. What helps most is having the following to hand:

• The list of recurring work, with rough hours against each item.
• The templates the firm actually uses for teasers, profiles and Information Memorandums.
• A decision on where client material is allowed to go, written down.
• The name of the person who will review the first system's output.
• Whoever administers the firm's Microsoft 365 tenant, or the IT provider who does.

With those in place a first working version can be in use within weeks, on live mandates, inside the tools the team already opens every morning.

The measure was set at the start: hours returned on the workflow it was built for. In practice the signal arrives earlier than the number does. The person who reviews the drafts stops rewriting them and starts editing them. The junior who used to assemble the document asks for the next workflow. Nobody opens the old spreadsheet to check.

The opposite signals are just as clear. If the team routes around the system, the workflow was wrong or the checkpoint sits in the wrong place, and that is a design problem to fix in the next cycle rather than an adoption problem to manage. A system that has to be encouraged is a system that is not yet doing the work. Watch for the quieter signal too. When people start asking for small changes rather than working around the system, it has become part of how the firm runs.

Do not start with a chatbot on the website, an all-staff AI subscription, or the workflow that is hardest and most impressive. Do not run three pilots at once; nobody reviews the results of three pilots. Do not let a tool decide the roadmap: the inventory decides, or senior time gets spent adapting the firm to software instead of the reverse.

And do not wait for the technology to settle, because it will not. The firms getting value are not the ones with the best model opinions; they are the ones that picked a bounded workflow, held the confidentiality line, and put the hours saved on the table where everyone could see them. That is available to any ten-person firm this quarter. None of it requires a view on which model will win, and none of it has to wait for the next release.