Matter intake breaks at the worst possible moment: a good client is finally ready to move, and you cannot yet tell them you are clear to act.
The enquiry lands through a form, a phone call, a forwarded email, a referral, or a partner who met someone at a conference. The names are half there. The other side is mentioned but never spelled out. A document is attached, but nobody renamed it. A filing deadline is sitting in the third paragraph of the message. Before anyone can run a conflict check or open the matter, someone has to reassemble facts the firm already holds, scattered across five places.
If you run intake, or you sit in the general counsel's office, or you are the partner waiting to say yes, you know the cost of that gap. The client reads the delay as indecision. This guide is about making that first stretch fast and calm, from the moment an enquiry arrives to the moment the matter opens cleanly. Ubisar does not give legal advice, and clearing a conflict and deciding to take a matter stay with your lawyers. What a system can do is make the state of every new enquiry visible, so those calls happen sooner instead of after a day of chasing.
What a clean intake actually settles
Strip away the software talk and a good intake process answers a short list of questions the same way every time. What came in, from which channel, and whose job is the next step. Who the client and the other side are, and whether any related names are still missing. Whether there is enough here to run a conflict check and open the matter, or not yet.
Notice what is not on that list: whether the firm should take the matter. The system never decides that. It gets a complete enough picture in front of the person who does, and it flags the moment that picture is ready. Everything below is in service of that one distinction, because the moment it blurs, a tool starts making calls that belong to a lawyer.
Where the hour before the conflict check goes
Right now that picture lives in a dozen places. The enquiry is in someone's inbox. The client's history is in the practice management system. The documents are in a folder nobody linked to. The partner's view is a chat message. Each step needs a slightly different cut of the same information, so the same names get typed in three times.
The delay is rarely the conflict check itself, which often runs in minutes once the names are clean. It is the hour before the check, when your team is chasing a middle name, a company number, or the second counterparty that was never written down. Multiply that by every new enquiry in a week and you can see where the intake coordinator's Tuesday went. Fix that hour and most of the felt slowness disappears, without touching the check itself.
Start with one list of live enquiries, not a new system
The first useful build is not a platform. It is a single list of live enquiries that everyone trusts. Each row carries the matter type, where it came from, who owns it, the parties named so far, the documents attached, what is still missing, any deadline spotted in the message, and where it stands: waiting on information, ready for a conflict check, or sitting with a partner.
Keep it simple enough that a front-desk assistant can update it under real Monday-morning volume. Capture the parties and the missing items in one place rather than in a reply-all thread. Link straight to the source document instead of re-describing it. Keep a plain record of what was received, what was asked for, and when. The discipline is not the tool; it is agreeing what a row must contain before an enquiry is allowed to move.
That last point is where most of the value sits. Before you connect anything, decide the small set of fields that must be present before an enquiry can go to a conflict check. Everything else can be added over time, but this minimum is what stops half-formed enquiries from clogging the check.
| Field | Why it has to be there | Where it usually comes from |
|---|---|---|
| The client's correct legal name | The conflict check runs on names, so a nickname or a trading name quietly misses matches | The enquiry, checked against a company register or the client's own letterhead |
| Every adverse and related party | A check that only covers the client is half a check | The enquiry message, the referring partner, the attached documents |
| Matter type and the service asked for | Decides which partner reviews it and which engagement template applies | The enquiry itself |
| Any deadline in the message | A filing date buried in a paragraph sets the whole priority | The email body or an attached notice |
| The documents, linked rather than described | The reviewer needs the source, not a paraphrase of it | The document system or the original attachment |
| Who owns the next step | An enquiry with no owner stalls silently | Assigned at the moment of capture |
Capture the enquiry once, in a form the next person can use
The first step is the one everyone underrates. Whoever takes the enquiry, the receptionist, the partner's assistant, the lawyer who was copied, drops what they know into the one list instead of leaving it in their own inbox. That single habit is where most intake either starts clean or starts broken.
It breaks in predictable ways. A partner forwards a promising email with "can we act on this?" and nothing else, so the parties never get logged. A phone enquiry gets a handwritten note that never makes it into the system. An existing client emails their usual contact directly, and the new matter rides inside a thread about an old one. In each case the facts exist; they are just sitting somewhere the next person cannot see. The point of capturing once is that the assistant running the check, the partner deciding, and the lawyer signing the engagement letter all read from the same row instead of reconstructing it three times.
Normalize the parties before you check anything
This is the step that decides whether the conflict check is worth running. A check is only as good as the names you feed it, and the names that arrive are almost never the names the firm holds. Someone writes "Henderson" when the register says "Henderson Group Holdings Ltd." The other side is described as "the landlord" with no entity behind it. A company is named, but the real risk sits with the individual who owns three of them.
Normalizing the parties means turning what arrived into what the check can actually search. The client's informal name becomes their registered legal name, with the informal one kept as an alias so nobody re-chases it. An unnamed adverse party gets named before the check runs, not after it comes back empty. A company gets connected to the people and the group behind it, because a conflict can sit with any of them. This is the legal analog of resolving which records refer to the same real entity: the tool can suggest matches and flag likely aliases, but the firm decides what a match means in its own context.
The care matters in both directions. Merge two entities that only share a common name and you can bury a real party. Treat a parent and its subsidiary as unrelated and you can miss a conflict that was there the whole time. Neither of these is a technical decision in the end. Someone who knows the client has to look.
| What arrives | Why it matters for the check | What the record should resolve it to |
|---|---|---|
| A company named by its trading name | The register and prior matters may hold a different legal name | The registered legal name, with the trading name kept as an alias |
| "The other side," mentioned once and never spelled out | An unnamed adverse party cannot be checked at all | A named party, chased and confirmed before the check runs |
| An individual behind a company | A conflict can sit with the person as well as the entity | Both the person and the entity, linked to each other |
| A group or parent structure | A conflict with a subsidiary is still a conflict for the firm | Each related entity, rolled up to the group |
| A common name shared with an unrelated party | A false match wastes a partner's time; a missed one is far worse | The specific entity, told apart by registration number or address |
Run the conflict check against a source you trust
With clean names, the check is the straightforward part. It runs the client, every adverse party, and the related parties against the firm's own history: past and current clients, parties the firm has acted against, and any restricted list the firm keeps. The rule that keeps this safe is narrow and worth stating plainly. The check runs against firm-approved sources only, never against whatever a general tool can find on the open internet.
Here the system earns its keep by holding the line. It can show that a conflict check is outstanding and keep the matter from opening until the check has run. It records what was searched and when, so there is never a question later about whether a party was covered. What it does not do is clear the conflict. That distinction is the whole reason the workflow is safe to automate: the machine assembles and holds, the lawyer decides.
Document the check and the decision the lawyer makes
A conflict check that leaves no trace is a liability, because six months later nobody can show what was searched or who signed off. So the record should carry the full picture: which parties were searched, what the check returned, who reviewed the results, and what they decided.
The decision is where the boundary is absolute. If the check comes back clean, the matter can move toward opening. If a potential conflict surfaces, the responsible lawyer, not the system and not the AI, decides whether it is a genuine conflict, whether the firm's rules allow it to proceed, and whether a waiver is possible and appropriate. A tool can lay out the hits and summarize why each one surfaced. It cannot judge them, and it must not appear to. Every summary it produces is a starting point for a person, and privilege and strategy never pass through it. Used this way, the record simply shows who made each call and when, which is exactly what you want the file to show if anyone ever asks.
Get the file complete before the engagement letter
Between a cleared check and an open matter sits the engagement letter, and it needs specific facts to be correct rather than approximate. The client's exact legal name, so the letter binds the right party. The scope, so the retainer says what the firm is and is not doing. The fee basis, agreed and written down. Who is engaging whom, especially where a parent instructs on behalf of a subsidiary.
The file is complete when those facts are present and the conflict check has cleared. At that point the matter is ready to open, and the person drafting the engagement letter is working from confirmed facts rather than filling gaps from memory. Most of the friction people blame on the engagement letter is really missing intake facts surfacing late, which is why getting the parties and the scope right earlier makes this step almost quiet.
Open the matter cleanly
Opening the matter is the last step and the easiest one to do badly under time pressure. Done cleanly, it means the matter number is assigned, the client and every party are in the system under their resolved names, the documents are linked rather than re-uploaded, the deadline is in the calendar, and the engagement letter has gone out. Done in a hurry, it means half of that happens now and the rest gets patched over the following week, which is how a party ends up missing from the very matter whose conflict check supposedly covered it.
The discipline that made the check reliable is the same discipline that makes the opening clean: everything the file needs is already in one place, so opening is a confirmation rather than a fresh scramble. Once the matter is open, the same habit carries straight into the legal client status reporting workflow, because the parties, documents, and deadlines the client will ask about are already logged.
A worked example, start to finish
The following is an invented scenario, written only to show how the steps connect. The names and details are illustrative, not a real matter.
A referral email arrives: an existing client wants help with a supply dispute against "Delta." That is all the partner forwards. The intake coordinator logs it to the one list, assigns an owner, and notes what is obviously missing, which is the identity of Delta. Normalizing the parties turns "Delta" into a real question, because three registered companies share that name; the referring partner confirms it trades as Delta Components Ltd, part of the Delta Group. The check then runs against Delta Components, the two other group entities, and the group itself, and it returns two hits: one is a dormant company the firm acted for years ago, the other is a live client. The responsible lawyer reviews both, judges the live one a genuine conflict, and declines that strand of the work. The matter opens against Delta Components only, with the scope and fee basis confirmed and the engagement letter out.
| Stage | What was in front of the team | What moved it forward |
|---|---|---|
| Enquiry arrives | A one-line referral: client wants help on a supply dispute with "Delta" | Logged to the list, owner assigned, Delta flagged as not yet identified |
| Normalize the parties | "Delta" matches three registered companies | Referring partner confirms Delta Components Ltd, part of the Delta Group |
| Run the check | The group has related entities the firm has dealt with before | Check run against all three entities and the group; two hits returned |
| Document and decide | One hit is a dormant former client, one is a live client | Responsible lawyer judges the live hit a genuine conflict and declines that strand |
| Open the matter | Client name, scope, and fee basis confirmed; check cleared for the remaining party | Matter opened against Delta Components only, engagement letter out |
Where AI helps, and where it must not
AI earns its place on the assembly work, the retyping nobody wants to own. It can read an incoming email and pull out the names, the dates, and the service being asked for. It can suggest the matter type. It can notice that a counterparty was named but never added, and normalize a trading name against the firm's records so the same entity is not entered three ways. It can draft the follow-up asking the client for the missing document, and it can draft a plain summary of what the conflict check returned.
It must not touch the calls that carry risk. It does not clear a conflict, accept a matter, decide a waiver, or offer anything resembling legal advice, and it works only against firm-approved sources. Every draft it produces is a starting point for a person to check. Kept inside those limits, AI removes the retyping and leaves the deciding where it belongs.
The systems this usually touches
Most firms already own everything this workflow needs. It usually connects the intake form, email, the CRM, the practice management system, the document system, your conflict-check tool, and the calendar and task systems that carry deadlines. You do not integrate all of them on day one, and trying to is how a simple improvement turns into a project nobody finishes.
The first real design choice is smaller than the systems map suggests: which handful of fields must be present before an enquiry is allowed to move to a conflict check. Settle that, connect the one or two systems that keep the list honest under real volume, and let the rest join over time as they prove they are worth the wiring.
Where this usually goes wrong
The failures here are consistent enough to name, and each has the same underlying cause: a decision that should have been settled once gets left implicit.
Forcing every matter through one rigid template
A new matter for an existing client is not the same as a walk-in dispute against a party the firm has never acted against. Push both through an identical form and the simple one carries the weight of the complex one, so people quietly route around the process for the easy cases and the list stops being trusted.
Letting the reason a matter was held live in free-text notes
If the reason an enquiry is stuck is buried in someone's note, it disappears the moment that person is on holiday. The state of a matter, waiting on information, waiting on a check, waiting on a partner, has to be a field anyone can read, not a sentence one person wrote.
Automating the chase before "complete" is defined
Automating the follow-up before the firm agrees what a complete enquiry contains just speeds up asking for the wrong things. Define the required fields first; the automation is only useful once it knows what it is chasing.
Normalizing party names too loosely
Merging two entities that only share a common name can bury a real party, and treating a parent and its subsidiary as unrelated can hide a conflict. The matching tool can flag the candidates, but a person who knows the client decides what is actually the same entity.
Trusting the check to a stale source
A conflict check run against a client list that is months out of date gives false comfort. The value of the check depends entirely on the source behind it being current and firm-approved, which is a maintenance job, not a one-time setup.
What tells you it's working
You do not need a dashboard to feel this improve, but a few numbers make it concrete. The time from an enquiry arriving to its record being complete enough to check. How many enquiries are stuck waiting on missing information right now. How long the average missing-information request has been open before someone closes it.
When those three move in the right direction, the softer signal follows on its own: partners stop asking where things stand, because they can already see it on the row. That is usually the moment the intake team notices the workflow has actually changed how the week feels, rather than just adding another screen to update.
How Ubisar would build this with you
In week one we would pick one enquiry type or practice area and follow real matters from first contact to the point a conflict check can run: what came in, who owns it, which parties and documents matter, and what is usually missing. The first thing you would have in hand is a working intake record for that enquiry type, with its required fields settled.
In weeks two and three we would connect only the systems that keep the list honest under real volume, and put AI behind the retyping: pulling out names and dates, normalizing party names against your records, spotting missing parties, drafting the follow-ups and the check summaries. Clearing conflicts and accepting matters stay with your lawyers throughout. By week four your intake team should be running live enquiries through the list and seeing at a glance which are ready to open.
We work one workflow at a time, month to month, starting from $4,000/month, and you can stop whenever it stops earning its place. If matter intake is the thing slowing your firm down, request a workflow review or get in touch, and we will map your first month against it.