Writing the client update is the fast part. Pulling together what actually goes in it is what eats the afternoon.
You know the moment. A partner asks where a matter stands before a Thursday call, or a general counsel wants one clean view across every matter your firm runs for them, and you go hunting. The last email thread. The document system. The time entries nobody has narrated yet. Two deadlines you half remember. By the time the update reads well, the afternoon is gone, and next month you rebuild it from scratch.
If you run a practice group, sit in a client relationship seat, or you are the associate who always ends up drafting the update, the useful fix is to turn that recurring reconstruction into something a lawyer can still read, correct, and own in minutes.
What a client actually wants to see in a matter update
A general counsel reading your update is not looking for reassurance. They are managing a set of matters, a budget they have to defend upstream, and a board or business owner who will ask them where things stand. What they want from you is the small set of facts that let them do their own job without calling you.
In plain terms, a good matter update answers a handful of questions the client would otherwise have to ask:
- Where is this matter now, and what changed since the last update?
- What happens next, and is there a deadline or a decision that sits with the client?
- What is this costing against what we agreed, and are we about to cross a threshold?
Everything else is detail. A litigation client wants to know whether the case moved toward resolution or further from it. A corporate client mid-deal wants to know what is blocking signing and who owns the blocker. A GC watching spend wants to know before the invoice arrives, not after. The report earns trust when it answers these before the client has to chase them.
The update is a judgment call; the gathering around it is not
What goes into a client update, how a risk is framed, what stays privileged, and what a client is ready to hear are all lawyer decisions. The work of assembling the raw material for those decisions is not. That assembly exists to put the right facts in front of the responsible lawyer so the judgment takes a few minutes instead of an afternoon of digging.
The duty to keep a client reasonably informed is not a courtesy; in the US it sits in the professional conduct rules most firms already work under (Model Rule 1.4 on communication). The problem is rarely that a firm disagrees with the duty. It is that meeting it well every month, across every active matter, quietly consumes the time of the people you least want doing clerical reconstruction.
So the target is narrow. Keep the judgment exactly where it belongs, with the lawyer, and take the fact-gathering off their desk.
Where the reporting time actually goes
Right now the status of a matter lives in a dozen places. Recent activity is spread across email and the document system. Deadlines are in a court calendar, a diary, and someone's memory. Time and disbursements sit in the billing system, often un-narrated. The strategic picture is in a partner's head. The person preparing the update asks around, copies notes, checks dates, reconciles the fee position, and stitches a message together from fragments.
None of that is hard work. It is undesigned work, so it happens by hand every time, and it happens differently depending on who is holding the pen that month. The associate who knows the matter writes a good update slowly. The one covering writes a thinner one and hopes nothing important was buried in a thread they never saw.
A quick test
Take one matter you reported on last month and try to rebuild the update from the systems alone, without asking a colleague. If you cannot see what changed, which deadlines are live, and where the fees stand against the estimate in a few minutes, the reporting is living in people's heads rather than in the file. That gap is what the workflow closes.
What the first useful version looks like
Start with one thing: a matter status packet. Not a client portal, not a new case management system. A single view that gathers what an update needs, carries a link back to the source behind every line, and produces a draft the responsible lawyer edits rather than writes from nothing.
The first packet pulls together what moved since the last update, with a link to the email, filing, or note behind it; the live deadlines and the one or two decisions that actually sit with the client; the fee position against the agreed estimate; and a drafted update the lawyer corrects and approves before anything reaches the client. The gathering is done, the sourcing is visible, and the human step becomes review instead of reconstruction.
What a matter status packet holds
| Matter | What changed | Next step and who owns it | Fees vs estimate | Review state |
|---|---|---|---|---|
| Contract negotiation | Two clause comments resolved, fallback terms still open | Client to confirm commercial terms this week | 60% of estimate, on track | Partner review |
| Employment advice | Client documents in, timeline still has gaps | Firm to confirm what facts are still needed | Under estimate | Waiting on client input |
| Litigation | Discovery tracker updated, two requests near deadline | Client to approve the scope of response | Approaching estimate, flag next month | Ready to draft |
Framing where the matter stands
The hardest line in a status update is the one that says where the matter actually is. "Progressing well" tells the client nothing and hides the fact they needed. A phase label the client can act on tells them a great deal: this matter is in discovery, this deal is in drafting with two open points, this advice is waiting on facts only the client can supply.
The packet should carry a plain phase for each matter and, next to it, the single next step and who owns it. That framing does two things. It stops the update from becoming vague, and it makes the client's own action obvious, which is usually the reason they read the update at all.
It also forces an honest internal question: what can the client see at this phase, and what stays inside the firm until the lawyer decides otherwise. A litigation matter mid-strategy is not the same disclosure as a routine filing.
What the client sees at each phase
| Matter phase | What the client can see | What stays with the lawyer for now |
|---|---|---|
| Opening | Matter opened, scope confirmed, first steps and expected timeline | Internal read on likely difficulty or exposure until it is assessed |
| Active work | What moved, next step, decisions the client owns, fees against estimate | Strategy options, privileged analysis, settlement thinking |
| Waiting on client or third party | Exactly what is blocking and who owns it | Nothing sensitive here; this phase is about clarity |
| Resolution or close | Outcome, final steps, final fee position | Internal notes and lessons not meant for the client file |
Talking about risk and exposure without overstepping
Clients want a read on risk, and this is exactly where an assembled update has to stop and hand over to a lawyer. A number, a probability, or a phrase like "we expect to win" can become a commitment the client relies on and later holds you to. Worse, a machine-drafted summary can restate privileged analysis in language that was never meant to leave the firm.
The safe design keeps risk language as a lawyer-written, lawyer-approved field. The packet can surface that a risk exists, that a deadline creates exposure, or that an open point could affect cost or timing, and it can pull the underlying facts together. It does not draft the assessment. When the update characterizes exposure, a lawyer writes that sentence, and a lawyer approves it before it goes out. Nothing privileged is summarized into client-facing text without that review.
Hold that line and the whole thing stays trustworthy. Blur it, and you have built a faster way to send the client something a lawyer never actually stood behind.
Budget versus actual, before the client asks
The fastest way to lose a client's trust in your reporting is a fee surprise. The status update is where you get ahead of it. A GC managing spend wants to know when a matter is tracking toward its estimate, not when the invoice has already blown through it.
The packet should carry a simple fee position for each matter: what has been incurred, how that sits against the agreed estimate or budget, and whether anything on the horizon will change the picture. This overlaps with how the firm cleans up its billing narratives and work in progress, and the two draw on the same time and matter data, so it is worth building them so one feeds the other rather than reconciling fees twice. In the status update the job is lighter: give the client an honest early read, so the invoice, when it lands, tells them nothing they did not already know.
Different clients want different updates
A standing report that suits one client will annoy another. The general counsel of a large corporate running fifteen matters with you wants a portfolio view: one page, every matter, phase and next step and spend, exceptions flagged. A founder who is your direct contact on a single dispute wants the opposite, a short plain-language note on that one matter. An institutional client with its own reporting obligations may want your update in a shape it can pass upward with little editing.
Deciding this upfront is most of the work. Get it wrong and you either bury a busy GC in fifteen separate emails or send a founder a portfolio grid they have to decode. The format and cadence should follow what the client actually does with the update.
Matching the update to the client
| Client | What they want | Sensible cadence | Format |
|---|---|---|---|
| Corporate GC, many matters | Portfolio view, exceptions flagged | Monthly, plus an alert on a threshold breach | One-page matter grid |
| Founder or owner, single matter | Plain read on their one matter | Monthly, or when something moves | Short written note |
| Institutional client with its own reporting | An update they can pass upward | Their reporting cadence | Structured fields they can reuse |
| Ad hoc or one-off matter | An answer on request | On request | Whatever suits the moment |
Which matters earn a recurring report
Not every matter deserves a standing update. A one-off filing does not need the cadence of a live dispute or a set of matters you run for a repeat client. Before you build anything, decide which matter types get a recurring report and what the shortest useful version contains. Get that wrong and you either drown clients in reports nobody reads or leave the important matters to memory.
The honest first cut is usually small: the handful of clients who expect updates on a schedule, plus the matters where a slipped deadline or a fee surprise actually hurts the relationship. Build for those, and let the rest stay on request.
Where AI does the assembling, and where a lawyer signs off
Once the packet exists, AI can do the gathering. Working from firm-approved sources, it can summarize what happened on a matter since the last update, pull deadlines out of documents and email, group the open items, draft the plain-status language, and bring the fee position together, with a link back to the matter file behind every line so a reviewer can click through instead of taking a summary on faith.
What it does not do is decide. It does not send client communications. It does not make the legal call, characterize risk, or touch privileged strategy. It does not skip review. A drafted paragraph is a starting point for the responsible lawyer, never the final word to the client, and anything client-facing is read and approved by a lawyer before it leaves the firm. The assembly can be automated; the judgment and the sign-off cannot.
The systems this reaches into
A working packet usually reaches into practice or matter management, the document system, email, court and diary calendars, the time and billing system, and sometimes a client portal. You do not connect all of it at once. The first build only needs enough to fill one matter type's packet for one client, and the value of the source links is that a reviewer can always click back to the underlying filing, note, or time entry rather than trust a summary.
One caution is specific to legal work: whatever you connect has to respect confidentiality and conflict boundaries. A packet for one client must never surface another client's matter, and internal-only fields have to stay internal even when the client-facing draft is generated from the same file. Design that separation in from the first build, not after.
A worked example
This one is illustrative, not a real client. Say a litigation boutique reports monthly to five corporate clients, each running three to six active matters. Today, one senior associate spends the better part of two days at month-end rebuilding those updates: opening matter files, scrolling email, checking the diary, chasing partners for the strategic line, and asking the billing clerk where fees stand. The updates are strong when she writes them and thin when she is on trial and someone else covers.
The first build is a single packet for the one client with the most matters. For each matter it shows what changed since last month with source links, the live deadlines, the next step and its owner, and the fee position against estimate. The associate stops reconstructing and starts reviewing: she reads each drafted line, corrects the phase where the machine misread a filing, writes the one risk sentence herself where the client needs a read, and approves it. A partner signs off the client-facing version. The two-day scramble becomes an afternoon, and the covering lawyer produces the same shape of update as the associate who knows the matter. The figures here are invented to show the pattern; a real build would measure the firm's own before and after.
What tends to go wrong
A few failure modes show up again and again.
The report nobody trusts
If the sources are not visible, lawyers re-check everything by hand and you are back to manual reconstruction with extra steps. Source links behind every line are what let a reviewer trust the packet enough to stop rebuilding it.
Judgment hiding in free text
An update that says "progressing well" hides the fact the client actually needed. A phase label, a next step, and an owner force the update to say something. The moment the report lets people write vague comfort language, it stops being useful.
Standardizing every matter at once
Trying to put every matter type on a standing report in month one guarantees a heavy, half-used system. The matters that genuinely repeat are few; start there and leave the rest on request.
Leaking what should stay inside
This is the most legal-specific failure. A generated draft that pulls from the full matter file can restate privileged analysis or, worse, surface another client's information. The separation between internal and client-facing fields, and the lawyer review before anything is sent, are what keep this from happening.
How to tell in month one whether it is working
You do not need a dashboard to know. The signal is simple: the person preparing updates spends the time approving clear exceptions instead of hunting across inboxes and the billing system, and the client comes away knowing exactly where each matter stands and what they have to do next. If that holds across two or three cycles, keep going. If the matter team still disagrees about what can be shared with a client, that is a policy question the workflow cannot settle, and it is better resolved first.
How Ubisar would build this with you
In week one, we pick one client's reporting cadence or one matter type and follow exactly how an update gets made today: the activity notes, the deadlines, the document status, the open questions, the fee position, the partner sign-off. The first thing you get back is a matter status packet with source links, client-visible fields kept separate from internal ones, the fee position against estimate, and a clear approval step.
Over the next two to three weeks we connect the minimum matter management, document, calendar, email, and time data that packet needs, and let AI summarize activity and draft the plain-status language from firm-approved sources, with a lawyer reviewing and a partner approving anything client-facing before it is sent. By week four, one reporting cycle should run from the packet instead of a manual hunt. This work usually pulls from matter intake and conflict checks and billing narrative cleanup, since the same matter facts feed all three, and it fits the way Ubisar runs its monthly implementation work: one workflow at a time, fixing the process, the data, and the tools together.
Sequencing the first cycle
| When | What happens | What exists by the end |
|---|---|---|
| Week 1 | Follow one client's reporting as it is done today; agree client-visible versus internal fields | A matter status packet design with source links and a sign-off step |
| Weeks 2 to 3 | Connect the minimum matter, document, calendar, and time data; add AI assembly from approved sources | Drafts assembled and sourced; lawyer edits, partner approves |
| Week 4 | Run one full reporting cycle from the packet | One client cycle produced by review, not reconstruction |
| Month 2 | Keep going if the packet cut the hunt and the client got a clearer view; widen to a second client or narrow if scope was too loose | An honest read on whether to extend |
If the monthly client update is quietly costing your team a day it does not have, send us the one matter type where it hurts most and we will map the first packet with you.