What a client-facing project management system actually needs

Most contractors already work in some task system. The question is not whether you have one, but whether it answers what the client asks: it was built for internal work, not for the conversation with whoever pays. This is a list of requirements, not of features. A large part of it exists in almost any tool, and where that is the case it is said here plainly.

1. An hour belongs to a task, not to a free-text line

The requirement: you cannot log an hour «just because». Every hour belongs to a task, and the task has a description.

Why this comes first: «why did this cost so much» is the one question every client repeats, and without the hour-to-task link there is no answer to it, only an explanation.

This exists nearly everywhere: Jira, Asana, monday, Clockify. If it is not enforced in yours, that is a configuration decision rather than a missing tool.

2. The rate is stored on the hour, not computed after the fact

The requirement: when an hour is logged, the rate in force that day is stored with it.

Why: rates change. If the amount is computed from the current rate, a January increase rewrites what was already invoiced for December, and the client receives an old report with a new total.

Many tools stumble here: they hold a rate on the person or on the project rather than a snapshot on the record. That is exactly the thing to check before replacing a tool.

3. A last-movement date that tells the truth

The requirement: a task has a date of last movement, and it marks a real event (a message, a status change, a decision) rather than the time of the last sync.

Why: a field that updates itself every night always looks healthy, and a task genuinely stuck for three months looks active in it.

A check worth running today: open a task nobody has touched for a month and see what that field says.

4. One place for the client, with a right of its own

The requirement: the client has their own entrance, and it is not «our system with fewer buttons».

Why these are not the same: an internal screen also holds what is not meant for them: internal cost, notes about the client themselves, other projects' queues. «Hidden by styling» comes back the moment somebody views the page source.

Tools differ widely here. A client portal exists in monday and Zoho; in Jira it is a plugin; in some tools there is none, and the answer becomes emailing a PDF.

And the real requirement hides in one detail: an allow list, not a deny list. Everything not explicitly marked visible stays hidden. A tool that hides by a list of exceptions will leak on the next data type somebody adds, because nobody will remember to add it to the list.

5. Money as a right separate from reports

The requirement: «can see reports» and «can see amounts» are two different rights.

Why: totting up hours can be delegated to an employee; seeing the rate at which the company sells to the client need not be. If it is one right, you will have to choose between «they get no reports» and «they know the margin».

Present in enterprise tools, almost absent in smaller ones.

6. A log of what left the building

The requirement: when a report was produced, who downloaded a file, what was sent to the client gets recorded.

Why: this is not bureaucracy but protection. «You never sent it to me» and «we did» cannot be settled without a record, and whoever has no log loses the argument even when they are right.

The subtle requirement: the row stays even for someone without the money right, and the values come off it. Hiding the row entirely is lying by silence: the person never learns that anything happened at all.

7. What is hanging, without having to ask

The requirement: a list that answers by itself: proposals with no reply, letters unanswered, tasks with no movement, dates gone by.

Why: every module knows about itself. The question «what is hanging on my side» belongs to no module, so usually nobody answers it until the client asks.

This is the widest gap between tools. Most systems have a «not updated since...» filter, and that is not the same thing: a filter needs somebody to open it. What is needed is a list that comes to you.

8. Correspondence tied to the work

The requirement: a letter can be attached to a task and is read alongside that task's history.

Why: «I asked for this by email» is the most common scope argument, and one link settles it.

Present in Zendesk and support tools; in project management systems, rarely.

9. An export you can hand to a client without touching it

The requirement: Excel and PDF at one click, in a shape you can send as is.

Why: an export that needs manual editing gets done once and then stops being done, and regular reporting disappears with it.

Present almost everywhere. What is worth checking is different: does the export contain what the client needs, or what is convenient to export.

10. Several clients in one tool, without a leak

The requirement: the separation between clients is enforced in one place, not in every query separately.

Why: the moment two clients share a system, every new screen is a chance to forget a condition. A separation that rests on «the developer will remember to add the WHERE» holds for a year and then breaks once, and that once costs you a client.

What to check in yours today: take a screen written recently and see whether the filter in it was written by hand. If it was, this is not a question of whether but of when.

11. Five questions to ask at a demo

Vendors always show the same three screens. These are the questions that show the rest:

1. «Show me an hour logged six months ago, after you changed a rate.» This is where point 2 comes out.
2. «Show me exactly what the client sees, from their account.» Not a screen that imitates it.
3. «Show me a task nobody has touched for two months.» What the movement field says.
4. «Show me who downloaded this report and when.»
5. «How do I see what is hanging without opening a filter?»

A question the vendor dislikes is not in itself a bad sign. The bad sign is the answer «that can be built».

12. One thing not worth demanding

Do not look for a tool that will write «what this actually was» for you. No system will write that sentence, because only whoever did the work knows it. A tool can make recording easier, remind, collect, but the sentence itself is written by hand, and it is precisely what turns an archive into memory.

We, for instance, have a knowledge base with meaning-based search, and it is empty: zero articles on the live project. The mechanism is written and works; what is missing is somebody writing the first article. That is not a failure of the tool, and another tool will not cure it.

How to use this list

Walk it with the tool you already have. Most points are probably already ticked. The ones that are not (2, 4, 5, 6, 7) produce most of the misunderstanding conversations with clients, and those are the ones worth checking before changing anything.

What each of them looks like in one system can be seen on the pages below.