Your Client Does Not Want a Project Management Login

A client asked us for edit access to our task board once. Not to a summary. Not to a status page. To the board — columns, assignees, priorities, the lot. We gave it to them, because that's what the tool we were using at the time offered as "transparency." Within a week they had renamed a column, reordered our sprint, and asked why a designer was marked as available when she was clearly, per the board, on a task for someone else.

She was on a task for someone else. She was also on maternity leave and the task was six weeks stale. The board was lying, the client believed it, and now the client was managing our staffing based on a lie we'd handed them the keys to.

What the client actually asked for

Go back to the original ask. Nobody emails an agency saying "I'd like row-level access to your task management instance." They ask two things, over and over, in every industry we've worked in: is this on track, and is there anything you need from me. That's the whole request. Everything else — the board, the swimlanes, the burndown chart — is something we built for ourselves and then, in a fit of generosity or fear, handed to someone who never asked for it.

The two questions are narrow on purpose. A client who asks "is this on track" does not want to derive the answer from fourteen tickets in various states of Doing. They want the answer stated. A client who asks "do you need anything from me" wants a specific, actionable ask — a file, a sign-off, a decision — not a standing invitation to browse your internal process and form opinions about it.

What a login actually does

A login does not answer either question. It hands over raw material and asks the client to do the interpretation themselves. That sounds efficient — self-serve! — but it isn't, for a specific reason: the client doesn't know your conventions.

They don't know that "Blocked" on your board means waiting on legal, not waiting on them. They don't know that a card sitting in To Do for two weeks is fine because it's scheduled for next sprint, not neglected. They don't know your priority labels, your color coding, or which of your three overlapping "review" columns means anything. So they fill in the gaps with the worst-case reading, because that's what people do with ambiguous information about work they're paying for. Then they email you asking why the homepage redesign looks stalled, and you spend twenty minutes explaining board hygiene instead of doing the redesign.

There's a second cost that's less obvious and worse. Once someone can see the whole board, they start having opinions about the whole board. Why is there a task for internal QA — can we cut that? Why does the copywriter have three other things assigned — is she overloaded, should we talk to her manager? A client with visibility into your operations will, with entirely good intentions, start operating your team. Not because they're difficult. Because you gave them a steering wheel and a windshield and no instructions not to touch it.

What visibility actually is

Visibility is not access to everything. It's a correct answer to the two questions, delivered in a form the client didn't have to learn to read. On track / not on track. Needs something from you / doesn't. If it doesn't answer one of those two questions, it's not visibility — it's exposure.

That distinction changes what you'd actually build or grant. Instead of a seat with edit rights to your whole workflow, a client needs a narrow, granted view of the specific work that's theirs, and a direct channel for the specific things they need to ask for or approve. Not the internal QA task. Not the other client's project sitting two rows down. Not your team's capacity planning. Just: here's what you asked about, here's where it stands, here's what we need from you and by when.

Guests instead of teammates

This is the shape we built into Team and Tricks on purpose. Clients and stakeholders come in as guests, not as members — they never occupy a seat, never show up in your roster, and never get assigned work. An admin grants a guest a specific project or specific tasks, and that's the whole of what they see. No company-wide board. No other client's project rendered visible by accident because someone forgot a permission checkbox.

When a guest needs something from you — a decision, a file, five minutes to approve a direction — they raise a request. It routes straight to the people who own the account, no guessing who to email, and it sits in a thread instead of scattering across inboxes. That's the channel back that a read-only link never gives you: the client can ask for something and get an answer where the work already lives, without being handed the wheel.

Comments, chat with TAI, and seeing who's on your team are each off for a guest by default. You turn them on per guest, per relationship, if it makes sense — a long-running client who's earned comment access is different from a one-off reviewer. The default is narrow because narrow is what most clients actually wanted in the first place.

The agency that stopped giving out logins

We watched a three-person consultancy make this switch mid-engagement, after a client had spent a month "helping" by reassigning tickets in their shared board. The agency pulled the login, granted the client visibility into exactly the three tasks that were theirs, and told the client to send anything urgent as a message instead of a board edit. The client pushed back for about a day. Then the requests started coming in — clean, specific, one thing at a time — and the reassigning stopped, because there was nothing left to reassign.

Nobody missed the dashboard. What they'd wanted the whole time was the answer to two questions and a way to ask for something when they needed it. The board was never the ask. It was just the thing that happened to be sitting there when someone said "can you give us some visibility."

The next time a client asks for access, it's worth asking them back: what do you actually need to know, and how often? Usually the answer is smaller than a login, and giving them the login anyway is how you end up explaining your own workflow to the person paying you to run it.