A client emails to ask why the homepage uses a different font from the one agreed in March. Someone remembers a decision being made. Nobody remembers where it was written down. Twenty minutes later you have searched three inboxes, a shared drive and a chat channel, and you are still not sure which version of the brief is the real one.

Most agencies and consultancies do write things down. The problem is that the writing ends up scattered, goes out of date, and stops being trusted. Once people stop trusting the documentation, they stop reading it, and then they stop updating it. This article looks at why that happens and at a workable routine: one notebook per project, with a light structure and a few habits that keep it alive.

Where project documentation actually goes to die

If you look honestly at a typical client project, the knowledge tends to sit in a handful of places, none of which were designed to hold it:

  • The shared drive. Folders named "Final", "Final v2" and "USE THIS ONE". The brief is in there somewhere, but so are four older versions of it.
  • Email threads. Decisions get agreed in a reply buried in a long thread with the client, and only the people copied in know about them.
  • Chat. Quick answers to important questions scroll out of view within a day.
  • The kickoff deck. Accurate in week one, quietly wrong by week four.
  • Someone's head. Usually the account lead's or the senior consultant's. This works until they go on holiday or move on.

None of these places is wrong for its original purpose. The trouble is that none of them answers the question a new team member asks on day one: what do I need to know about this project, and where is the current version?

Why it happens

Documentation rarely dies from neglect alone. It usually dies for a few predictable reasons.

There is no obvious home

If a project has no agreed place for its documentation, each person picks their own. The designer keeps notes in their design tool, the developer in a text file, the account manager in email. Each choice is sensible on its own, and together they produce a mess.

Documents are written once and never revisited

Briefs, scopes and technical notes are usually written at the start, when energy is high. Then the project changes and the documents don't. After a few weeks, people learn that the document can't be relied on, so they ask a colleague instead.

Documentation lives away from the work

When the tasks are in one tool and the documents in another, updating the documentation becomes a separate chore. Chores that sit outside the daily flow of work get skipped in busy weeks, and agencies have a lot of busy weeks.

Nobody owns it

"The team" owning the documentation usually means nobody does. Without a named person, nobody notices when a page is out of date.

Too much ceremony

Some teams overcorrect with elaborate templates and approval steps. Writing a quick note then feels like filing a form, so people go back to chat.

The approach: one notebook per project

The fix doesn't need to be clever. Give every client project a single, agreed place for its written knowledge, keep it next to the tasks, and give it just enough structure that people know where things go.

In Tilvin, each project already groups its task lists, messages, files and time logs in one place, and it can also hold notebooks: rich-text documentation with categories, attachments, optional version control and export to Word or PDF. (The features overview lists the rest of what sits inside a project.) The tool matters less than the rule, though. Whatever you use, the principle is the same: if it is knowledge about this project, it lives in this project's notebook.

A light structure helps. For a generic example, a six-person design agency might use these categories for every client project:

  • Brief and scope: the current agreed scope, with a short note of what changed and when.
  • Decisions: one line per decision, with the date, who agreed it and why. This is the page that answers the font question in seconds.
  • Client and contacts: who approves what, preferred channels, working hours, sensitivities.
  • Technical and access notes: environments, hosting details, how things are set up. Keep actual passwords in a proper password manager, not the notebook.
  • Brand and style: fonts, colours, tone of voice, with reference files attached.
  • Handover: what someone joining mid-project needs to read first.

Using the same categories on every project matters more than choosing the perfect ones. When people move between projects, they already know where to look.

Habits that keep the notebook alive

Structure gets the notebook started. Habits keep it accurate. These are small on purpose.

  1. Name an owner per project. Usually the project manager or account lead. They don't write everything, but they check it is current and nudge others when it isn't.
  2. Tie updates to events, not to a calendar. A scope change, a signed-off design or a decision in a client call should each trigger a notebook update the same day. "We'll tidy the docs on Friday" rarely survives Friday.
  3. Write short entries. A three-line decision note written today beats a polished page that never gets written. Dated bullet points are fine.
  4. Turn on version control for pages people argue about. Scope and brief pages benefit most. Being able to see what a page said last month settles disagreements calmly.
  5. Point to the notebook instead of re-explaining. When someone asks a question in a task discussion, answer briefly and point them to the relevant notebook page. People learn to check there first.
  6. Review it at milestones. At each phase sign-off, the owner skims the notebook for anything stale. Ten minutes is usually enough.

What doesn't belong in the notebook

A notebook stays useful partly because of what you keep out of it. If it fills up with to-do lists and conversation, it turns into another place where things get lost.

  • Work to be done belongs in tasks, with an assignee and a date. If a notebook entry implies action, create the task and keep the notebook entry as the reasoning behind it. Keeping requests in one task list per project is covered in why client requests get lost.
  • Back-and-forth discussion belongs in the task's discussion thread, where it stays next to the work. Once a conclusion is reached, record the outcome in the notebook's decisions page.
  • Working files such as drafts and exports belong in the project's files, attached to the relevant tasks. Attach only reference material to the notebook, such as the final brand guide or the signed scope.
  • Diagrams such as sitemaps or system sketches can be kept as project drawings and exported as PNG where they need to sit in a document.

A useful test: the notebook should explain what we know and what we agreed. Tasks explain what we are doing. Discussions explain how we got there.

Practical next steps

You don't need to fix every past project. Start small and let the habit spread.

  1. Pick one active client project that has caused documentation pain recently.
  2. Create its notebook with the six categories above, or your own short list, and agree to reuse them on every new project.
  3. Move in the current essentials only: the latest scope, the key contacts, and the decisions you can confirm. Leave old versions where they are.
  4. Name the owner and agree the update triggers: scope change, sign-off, client decision.
  5. Tell the client-facing team to answer repeat questions by pointing to the notebook.
  6. At the next milestone, review it. If people used it, roll the same structure out to new projects. When a client or a new starter needs a snapshot, export the relevant pages to PDF or Word rather than rewriting them.

The aim isn't perfect documentation. It's documentation people trust enough to check first, because it lives where the work lives and somebody keeps it current.