Thought

Business

How to run client meetings that move digital projects forward: what we fix before the call

<p>How to run client meetings that move digital projects forward: what we fix before the call</p>

Most project meetings fail for the same three reasons: the wrong people are in the room, no decision is actually on the table, and no one writes down what was agreed. Running a meeting well is less about etiquette and more about these three fixes — use it whenever a meeting will shape project scope, timeline, or ownership.

Why most project meetings fail

From our project work, the same three patterns show up across industries — from SaaS startups to mid-market e-commerce teams to in-house marketing leaders at larger organizations:

- The decision-maker isn't on the call. Everyone discusses the problem, but the person who can sign off is out of office or in another meeting. The call ends with a vague "let me check internally" — and nothing moves for a week.

- No decision is on the table. The meeting is framed as a "sync" or a "quick update." Thirty minutes in, there's still no clear question anyone is trying to answer. People leave feeling busy but not productive.

- No written record. The call ends, everyone agrees on something, and four days later each person remembers a slightly different version. Rework follows.-

Everything below is a fix for one of those three.

 

How we apply it — running meetings with clients

Step 1: Write the agenda before the invite goes out

We do not send a meeting invite without an agenda. The agenda has three things: the outcome we need (not just the topic), the decision owner for that outcome, and a time budget for each item. If we can't write those three lines, the meeting doesn't exist yet — something needs to be sorted over email or a shared doc first.

This is also our filter for who should attend. If an item needs a decision, the person who can make it has to be on the call. If they can't attend, we reschedule.

 

Step 2: Match the format to the purpose

We meet online by default — calendar tools handle timezone differences, and our team is set up for remote work. But format isn't a matter of preference; it's a decision about what the meeting needs to do.

We meet in person when a contract or scope is being signed off, when we're meeting a new client for the first time, or when a creative review benefits from seeing reactions in the room. We meet online for status updates, weekly syncs, working sessions, and most mid-project check-ins.

For the online side, we run a short tech check before every call: connection, microphone, camera, screen-share permissions. We only open the files we'll share and close everything else — client meetings aren't the time for a stray tab to appear.

For in-person meetings, we confirm the venue, plan travel time, check any building access requirements, and bring the equipment we need to present. Same rule on the laptop: close anything that isn't the meeting material.

 

Step 3: Open the call with a 90-second recap

Every call starts the same way: we state the outcome we need from the meeting, read the agenda, and confirm the time budget. It takes about 90 seconds and saves the first 15 minutes of drift. It also gives the client a chance to add something or flag that a decision is premature before we spend the call on it.

 

Internal meetings — same rules, smaller audience

Our internal meetings follow the same structure: agenda, outcome, time budget, summary. The difference is that the "client" is the team, and the decisions are about how we staff, sequence, or unblock work. We run weekly team syncs online because we work remotely, and we keep them short — if there's no decision to make that week, we cancel the meeting and use the time to write.

 

Red flags before a client meeting

We treat these as signs a meeting will waste everyone's time — and we fix them before the call, not after:

- The agenda went out less than 24 hours before the meeting. 
Fix: send it with the invite, not the morning of.

- There's no named decision owner for the outcome. 
Fix: identify who can actually say yes or no before scheduling.

- The meeting is labeled "quick sync" or "brief catch-up" with no defined outcome.
Fix: rename the meeting after the decision it should produce.

- More than six attendees and several have no clear role.
Fix: move optional attendees to an FYI recipient list for the summary instead.

- A discussion item has been on three consecutive agendas without resolution.
Fix: take it offline — it isn't a meeting topic, it's a stuck decision that needs owner-level escalation.

 

The meeting summary — what we send and why

Every client meeting gets a written summary, usually within the same business day. The shape is consistent enough that anyone on our team can produce one:

- Subject line: [Project Name] — [Date] meeting summary + actions

- Decisions made: short bullets, one decision per line, with who decided

- Action items: task, owner, due date — no ambiguous owners

- Open questions: what we still need answered, and from whom

- Next step: the next meeting or deliverable, with a date

We close the summary by asking the client to confirm within a specified window (usually one or two business days) before we start on the action items. That confirmation is the part most teams skip — and the one that most often prevents rework.

 

When this matters most vs. when you can be lighter

Full agenda + summary treatment is necessary when:

- Scope, timeline, or budget is changing

- A new stakeholder is being introduced to the project

- A handoff is happening between teams or phases

- The discussion depends on something on the client's side

 

You can be lighter when:

- The team has met weekly for a long time and the cadence is stable

- The call is a working session, not a decision call (still send a short recap, not a full summary)

- The meeting is a 1:1 relationship check-in

 

The meeting is the cheapest part of any project. The cost of a bad one shows up in rework — not on the calendar.

Share

Writer
Account Executive

Worakamol Sojiwisan