Client Meeting Notes Template
Client meeting notes record what both sides discussed and agreed: the requirements the client raised, the commitments each side made, the scope that was settled, and the next steps with dates. The template below covers all of it, with a filled-in example and a free Word file.
Unlike internal minutes, client meeting notes serve a protective function. When scope is remembered differently three months later, the only thing that settles it is the record you sent and the client did not dispute. That is why this template keeps what was agreed strictly separate from what was merely proposed.
This page covers the structure, guidance for each field, an example from a services company meeting, the mistakes that lead to disputes later, and a short FAQ.
A .docx file that opens in Word, Google Docs and LibreOffice.
When to use this template
Use it for any meeting with someone outside your organisation: discovery calls, proposal presentations, recurring progress reviews, and escalation meetings. It works for supplier meetings too, simply by swapping the two sides.
For the launch meeting of a project already under contract, the project kickoff template is a better fit because it adds detailed role assignment and milestone sections.
What all these situations share is that at least one person outside your organisation will read the notes. That changes how you write: the text must make sense without internal context, and it must not contain judgements about the client.
Client meeting notes structure
The eleven fields below form the full structure. The three that matter most are client requirements, what was agreed and what was not agreed, because those are the ones reread when a disagreement surfaces.
| Field | How to fill it in |
|---|---|
| Meeting name | Name the client, the topic and the session number, for example Session 2 with Company A on phase 1 scope. Numbering the sessions links the series together. |
| Time and format | Date, time, duration and format. For an on-site meeting, record the location as well, since it matters when reconciling travel costs. |
| Attendees on both sides | List the client side and your side separately, with job titles. Titles matter because they show who has authority to agree and who is only contributing input. |
| Meeting objective | One or two sentences on what needs to be achieved. Agree this with the client at the top of the meeting so both sides know what a successful session looks like. |
| Client requirements raised | Record the client's own words rather than your interpretation of them. If a requirement is unclear, note the clarifying question instead of guessing and recording the guess. |
| Options presented | The options you put forward with the trade-offs you described. This section documents the advisory process, which is useful when the client later asks why this direction was chosen. |
| What was agreed | Only what both sides clearly accepted. Each entry records what was agreed and who on the client side agreed to it. This carries the most weight of anything in the document. |
| What was not agreed | Open points, with the reason and an expected decision date. This section matters as much as the previous one, because it blocks the assumption that silence meant agreement. |
| Scope changes, if any | If the meeting produced requests beyond the signed scope, record them in their own section and state the effect on timeline and cost. Do not fold them into the general requirements list. |
| Action items for both sides | A four-column table with an added column for which side owns the item. Client-side tasks must be recorded too, because most project delays come from waiting on the client for something. |
| Next session | Expected date and expected agenda. Settling this in the room saves several rounds of email afterwards. |
Filled-in example
A second working session between a software services company and its client. Names and figures are illustrative.
| Field | Example content |
|---|---|
| Meeting name | Session 2 with Company A on phase 1 scope |
| Time | Thursday 23 July 2026, 14:00, ran 65 minutes, on site at Company A |
| Client side | Ms Hanh (COO, authority to approve), Mr Tu (Warehouse manager) |
| Our side | Anh (project manager), Trang (business analyst) |
| Objective | Settle the phase 1 feature list and agree the delivery date |
| Client requirements | Real-time stock visibility across all three warehouses. Month-end reporting in their existing internal format. Ms Hanh also raised interest in a mobile app without specifying scope. |
| Options presented | Option 1: web platform first, mobile app in phase 2. Option 2: both in parallel, 6 weeks longer and 40 percent higher cost. |
| What was agreed | Option 1 selected. Phase 1 covers real-time stock across three warehouses and month-end reporting. Delivery date 30 September 2026. Agreed by Ms Hanh. |
| What was not agreed | Mobile app scope for phase 2. The client needs an internal discussion, expected response before 15 August. |
| Scope changes | The mobile app request falls outside the current contract and will be quoted separately once the client confirms scope. |
| Action items | Send the current month-end report format · client side, Mr Tu · 28 July. Send the detailed phase 1 specification · our side, Trang · 26 July. Prepare the mobile app quotation · our side, Anh · after the client confirms scope. |
| Next session | Expected 20 August 2026, review of the detailed specification |
Sending the notes and asking for confirmation
Client meeting notes only carry weight once the client has read them and not objected. Send within twenty-four hours with an explicit request: please review and respond by a given date, and if we do not hear back we will take the content as correct.
That last sentence matters more than it looks. It converts silence into agreement transparently, and that is what lets you rely on the document later. Without it, a client can reasonably say they never confirmed anything.
For anything affecting cost or deadlines, ask for an active confirmation by reply rather than relying on silence. The level of formality should track the value of what is being settled.
Separating requirements, proposals and commitments
These three get mixed together constantly and that is the source of most scope disputes. A requirement is what the client wants. A proposal is what you offer to meet it. A commitment is what you promise to deliver, with a date.
A line like we will look into integrating with the accounting system is not a commitment, but a client will very reasonably read it as one. If you are not certain, write that you will assess feasibility and respond by a specific date rather than leaving the sentence hanging.
In the document these three belong in three separate sections rather than one list. That structural separation reduces misunderstanding without needing a single extra word of explanation.
Recording requests that fall outside scope
During a meeting clients routinely raise wishes that sit outside the signed scope. The natural reflex is to nod and note it down to keep the atmosphere pleasant, and that is exactly where a project starts to expand.
The healthy handling is to record it fully but place it in a clearly labelled scope change section with a line about the effect on timeline and cost. This needs no confrontation in the room, just a neutral sentence such as that sits outside the current scope, we will quote it separately.
Projects almost never expand because of one large request. They expand because of ten small ones, each nodded through in a different meeting, none of them written down.
Writing notes an outsider can read
Client meeting notes get read by people who were not in the room, typically finance, legal, or the attendee's manager. Internal abbreviations and team-specific naming make the document opaque to precisely the people with decision-making authority.
For the same reason, the notes should contain no judgements about the client. A line like the client still does not understand their own requirements may well be accurate, but once a third reader sees it, the damage to the relationship outweighs any benefit it ever provided.
A simple check: reread the notes and ask whether, if the client forwarded this to their entire leadership team, there is any sentence you would want back. If there is, fix it before sending.
Five mistakes that cause disputes later
When both live in one section, each side remembers it in whichever way suits them. Separating from the start is the cheapest possible prevention.
Record what the client actually said, with a clarifying question attached if it is unclear. Interpreting early is the fastest way to be wrong from the beginning without anyone noticing.
Out-of-scope requests need their own section with a line about timeline and cost impact, not a place in the general requirements list.
Most delays come from waiting on client data or approvals. Without a record there is no basis for explaining the cause of a slip later.
Late notes lose their confirming power, because the client has already started acting on their own understanding. Within twenty-four hours is the mark to hold.
FAQ
Do client meeting notes need to be signed?
For an ordinary working session, no. Sending them by email with a request for a response within a deadline is enough. Signatures matter when the notes support a contract change, a price change, or a formal acceptance.
How quickly should notes be sent to the client?
Within twenty-four hours. Past that point both sides have begun acting on their own reading, and the notes lose most of their power to align understanding.
Should client meetings be recorded?
You can, but ask permission explicitly before you start and respect a refusal. When permission is granted, recording means the client's requirements get captured in their own words rather than through your interpretation.
What if the client says the notes are wrong?
Correct them and send an updated version, keeping both versions rather than overwriting. A client responding is a good sign: it means the notes are doing their job of aligning understanding before a difference becomes a dispute.
How do client notes differ from internal minutes?
In who reads them. Client notes will be read outside your organisation, so they avoid internal abbreviations, contain no judgements about the client, and keep what was agreed strictly separate from what was only proposed.
Record the session and let Meco write the notes
In a client meeting the note taker usually misses the details that matter most, because they are listening and writing at the same time. Meco records the session and produces notes with a requirements section, what was agreed, and an action item table with named owners.
Meco captures both on-site meetings at a client office and phone calls, the situations where conferencing platform bots cannot join. Remember to ask the client's permission before recording.
Try it free