How to Track Client Approvals Without Digging Through Email

Marisol approved the homepage design on a Tuesday. She said so in an email: "Looks good, let's move forward!" Three weeks later, during a dispute about a last-minute logo swap she insists she never signed off on, someone on the agency side has to find that email, confirm it was actually about the homepage and not the earlier draft, and check whether "looks good" covered the logo or just the layout.

It did. Sort of. The email also said "can we tweak the logo placement a bit?" which either means the homepage was approved with one open item, or means nothing was approved at all. Nobody can say for certain, because the email was a message, not a decision. A message describes a feeling. An approval has to describe a state.

Approval is a transition, not a tone

"Looks good" is sentiment. It tells you the client is pleased, which is nice, and it tells you nothing enforceable. A real approval record answers five questions without anyone having to interpret anything:

• What exactly was being approved (which item, which version)
• Who approved it (a specific named person, not "the client")
• What they decided (approved, approved with changes, rejected)
• When they decided it (a timestamp, not "a while back")
• What happens next if the decision wasn't a clean yes (a task, with an owner)

Email can hold all five pieces of information. It just doesn't hold them in one place, doesn't timestamp decisions distinctly from small talk, and doesn't connect the decision to the work that follows. You end up with the information scattered across three threads and a Slack DM, and finding it later means reading instead of looking something up.

Give the client a channel that isn't a reply-all

In Team and Tricks, a client like Marisol doesn't get a teammate account. She gets guest access to the specific project — in this case, the website rebuild — and nothing outside it. She never shows up in the Members list, she's never assigned a task, and she doesn't take a paid seat. What she can do, once the agency turns it on for her, is raise a request.

A request is the right shape for this because an approval isn't owned work. Marisol isn't doing a task. She's being asked for a decision, and the agency needs that decision in a form that survives the project. When a guest raises a request, it routes automatically to the organisation's owners, admins, and managers — nobody has to remember to loop in the right person, and Marisol doesn't have to guess who "the right person" even is.

What the record actually looks like

The agency sends the request with the specific thing attached: homepage design, v3, with a note naming exactly what changed since v2. Inside that request thread, a message can be flagged for formal request approval — a distinct marker from an ordinary reply, and separate from time entry approval, which is a different thing entirely used for billable hours. When Marisol replies inside that thread, her decision sits against a timestamp, attached to that specific request, which is attached to that specific project. Nobody has to cross-reference which email client she was using or scroll past an out-of-office autoreply to find it.

Here's the shape of what you end up with, written out as a reference, not as a new feature you have to configure — it's just what the request thread already contains once you use it this way:

Item:          Homepage design, v3
Requested by:  Agency (sent via Request)
Recipient:     Marisol (guest, Website Rebuild project)
Decision:      Approved with changes
Timestamp:     Oct 14, 2:41pm
Note:          "Logo needs to sit higher, everything else is good"
Resulting task: "Adjust logo placement, homepage v3" — Classic task, assigned to Dana

That last line is the part email can't do on its own. "Approved with changes" isn't a resting state — it's an instruction to make a task. The request told you what changed and who signed off on it; the task is where that gets done and gets tracked separately from the approval itself. If someone later asks "did the client ever actually approve the homepage," the answer isn't a search through a mailbox. It's the request thread, with the decision and the timestamp sitting right there.

What Marisol never gets to touch

It matters just as much what she can't do. She can't see the agency's internal project chat about whether the logo placement was actually Dana's mistake or the client's second-guessing. She can't be assigned the "adjust logo placement" task — that stays with Dana, a teammate, because approval and execution are different kinds of work done by different kinds of people. She can't open the agency's timesheet or see other clients' projects sitting in the same workspace. Comments, if the agency hasn't turned that on for her specifically, aren't open to her either. None of that is withheld to be stingy. It's withheld because a client approving a design doesn't need the agency's internal billing argument, and giving her that view wouldn't make the approval any more real.

Why this beats a shared doc too

Some agencies solve this with a shared spreadsheet: item, approver, date, status, column after column. It works until someone forgets to update it, which is the same failure mode as a stale task board — the record is only honest if updating it is cheap, and a spreadsheet makes updating it a separate chore from actually getting the approval. A request thread doesn't have that problem, because the approval and the record are the same action. Marisol isn't filling out a form about her decision. Her decision is the record.

The dispute about the logo never needs to happen twice. Next time there's a "wait, did we actually approve that," the answer is one request thread away, not a Tuesday three weeks back that somebody half-remembers.