Client Project Tracker: What Clients Should See

A client project tracker should show the client four things: what is being worked on, where each piece stands, what is waiting on them, and what was finished recently. It should not show your internal priorities, other clients, rough notes, or anything about cost and margin. Write each line in the client’s words, give them access to see and comment but not change, and keep it current so they stop asking for status calls. The columns, the access rules, the update rhythm and the traps of sharing a spreadsheet are below.

If you need the internal tracker, with owners, priority and blocked-by across several projects, start with the project tracker template. This page is about the view you hand to the client, which is a different document with a different reader.

What clients should see

• The deliverables they are paying for, named the way they would name them: “Homepage design,” not “FE layout pass 2.”
• A status for each one, from a short fixed list.
• What is waiting on them, with a date. This is the line that saves you the most time, because clients usually do not know they are the blocker.
• What was finished recently, and where to review it.
• Decisions made along the way, so nobody reopens them in month three.
• A way to ask a question about a specific item, attached to that item.

What clients should not see

• Other clients, their names or their work. A single shared tracker with a client filter is the most common way this leaks.
• Internal priority numbers. A client who sees their request ranked 7 will ask why, and the honest answer usually involves another client.
• Rough notes, guesses and internal debate. “Client’s copy is weak, rewrite quietly” is fine to think and fatal to share.
• Hours, rates, cost and margin, unless your contract is time and materials and the client expects to see them.
• Anyone’s performance, or who made a mistake. Report what happened and what changed.

The columns, in the client’s words

A client tracker needs fewer columns than an internal one, and every value should make sense to someone who has never seen your process.

Deliverable,Status,Waiting on,Needed by,Last update,Where to review
[What they asked for],Planned,,,[Month day],
[What they asked for],Up next,,,[Month day],
[What they asked for],In progress,You: [what],[Month day],[Month day],[link]
[What they asked for],Done,,,[Month day],[link]

• Deliverable: the thing they will receive, not the internal task. One deliverable may be twenty tasks on your side.
• Status: four values, fixed. Planned, Up next, In progress, Done. Resist “Almost done.”
• Waiting on: filled only when the client is the blocker, starting with “You:” so it cannot be missed. When you are the blocker, it is your problem to solve, not a column for them to read.
• Needed by: the date you need their input, not the delivery date. Delivery dates go in the plan or the contract.
• Last update: the date the row last changed. A row with an old date is a question the client will ask; answer it first.

Deliverable,Status,Waiting on,Needed by,Last update,Where to review
Homepage design,In progress,,,Sep 28,
About page,In progress,You: final About page copy,Oct 3,Sep 26,
Hosting and domain,Up next,You: registrar login,Oct 2,Sep 25,
Contact form,Planned,,,Sep 20,
Brand colors and fonts,Done,,,Sep 19,Style guide PDF in shared folder

What the client should be able to do

Give clients the least access that does the job. NIST defines least privilege↗ (opens in a new tab) as restricting access “to the minimum necessary to accomplish assigned tasks,” and for most clients the task is reading and asking. Two levels cover nearly everyone:

• See and comment. The default. They follow progress and ask questions on the item itself, but cannot move statuses, edit your wording or delete anything.
• See, comment and add requests. For clients who send a steady stream of change requests or bug reports. They can add new items and edit their own, but not change yours.
• Never edit. A client who can edit statuses will, eventually, move something to Done that is not.

Sharing a spreadsheet tracker safely

A spreadsheet is a fine client tracker if it is a separate file per client. Google Docs, Sheets and Slides offer three sharing levels↗ (opens in a new tab), Viewer, Commenter and Editor, and Commenter matches “see and comment.” The owner can also turn off downloading, printing and copying for viewers and commenters.

What a spreadsheet will not do is hide rows from someone who can open the file. A filtered master sheet is not a client view: Google’s help page on filter views↗ (opens in a new tab) notes that someone with view-only permission can create a temporary filter view of their own, so the filter you set does not limit what they can look at. Keep one file per client, and copy updates into it from your internal tracker.

How often to update it, and how

• Change a row the day it changes. A tracker that is updated once a week before the status call is a report, not a tracker.
• Send a short written update weekly anyway, pointing at the tracker: what finished, what is next, what you need from them and by when. The weekly status report template has a client version.
• Answer questions where they are asked, on the item, so the answer stays attached to the work.
• Record decisions the day they are made, in a sentence the client would agree with: what, who decided, when.
• Archive Done items after a month into a “Delivered” list. Clients like to see the list grow; they do not need to scroll past it.

A client tracker on a fenbs board

On fenbs, the client does not get a copy of the tracker. They get a place on the board. Make one team board per client, because a role applies to the whole board: a client added to a board sees everything on it, so other clients’ work never belongs there. The client project board template is set up for exactly this.

• Roles are set per company, and two are suggested for sharing, one press each to add. A Client sees the board, live, and comments, and cannot change anything. A Reporter adds tasks and comments, and edits only their own.
• The lanes are the status column: To Do, Next Up, In Progress and Completed. Nobody maintains a status by hand.
• Each task has a note for the problem and a plan for how it will be done. Write both knowing the client reads them.
• Ask someone, on any task, adds a person by email with a role and posts your question as a comment on that task. Use it for the “Waiting on you” moment: the client gets one email with a link to the board, and the question sits on the item it is about.
• Decisions go on the Decisions and rules page, with who decided and when.
• History records who changed what, so “when did this move?” has an answer. Someone with the suggested Client role sees what changed and when, but not who made each change.

Some things work differently from a spreadsheet. A client sees the board only by being added to it with a role; there is no link to send around. fenbs has no due dates and no assignee field you can set, so “Needed by” dates and who is responsible go in the task note. Internal priority numbers, 1 to 10, are visible to anyone on the board, so if a client should not see your ranking, explain it once or leave priorities off that board. More on what each role can do is in roles and permissions for humans and AI agents.