Why every website request should be logged: running projects through a client portal

Most website projects that go wrong do not fail on design or code. They fail on memory. Someone asked for a change on a call. Someone else approved a draft in a WhatsApp voice note. A third person sent a new logo by email to the wrong address. Three weeks later, nobody agrees on what was requested, what was done or who said yes.

The fix is unglamorous: log every request.

01Why should every website request be logged?

Because unlogged requests get lost, duplicated, misremembered or disputed. A log gives every request one record with an owner, a status and a history, so both the client and the studio can see what was asked, what was done and who approved it, at any point, without relying on anyone's memory.

This is the passage we share when clients ask why we insist on it. Logging is not about distrust. It is about respect for everyone's time and for the work itself. A business owner should not have to chase a request they made a fortnight ago, and they should not have to wonder whether it was heard. A developer should not have to scroll through three chat threads to work out which version of the wording is final. When every request has one record, both sides can see its status at a glance: received, in progress, ready for review, approved, live. When every change has a history, a question like "when did this price change and who asked for it?" takes seconds to answer rather than an afternoon of searching. And when every draft carries an approval, launch day is calm because nothing is a surprise. That calm is the real product.

02What is a client portal?

A client portal is a shared workspace where every request, draft, change and approval for a project is recorded in one place. The client submits and tracks requests; the studio updates status, shares review links and records what changed. Both sides see the same history.

It replaces the patchwork of inboxes, chat threads and spreadsheets most projects drift into. It does not replace conversation; it gives conversation somewhere to land.

03How does the Client Ops Portal work?

The Client Ops Portal is the system our studio builds and runs, and every client project runs through it. Every request is logged, each draft gets one review link, there is a full change history, and every approval is recorded in a trail.

Its four principles map directly to the problems above:

1. Every request logged. Whether it arrives by call, email or WhatsApp, it becomes a record with an owner and a status.
2. One review link per draft. You see the draft in a browser, comment once in one place, and approve. No attachments, no version confusion.
3. Full change history. What changed, when and at whose request.
4. An approval trail. Who agreed to what, recorded before anything goes live.

You can see it listed with our other products on the services page, and it is part of how a project runs as described on our studio page.

Fig. 01Cycle

The life of a request

1. Request: Logged with page, change and reason
2. Owner: Assigned and acknowledged
3. Draft: One review link
4. Approve: Recorded in the trail
5. Live: Change history updated

The last step leads back to the first.

04What about clients who prefer WhatsApp?

Keep WhatsApp for conversation and log the requests that come out of it. Many clients in India and the UAE prefer to message, and that is fine. The rule is simply that a request is not a request until it is in the portal, where it gets an owner and a status.

In practice, a project lead who receives a request on WhatsApp logs it in the portal and replies with the link. The client keeps the convenience of chat and gains a record they can check. UK clients more often prefer email, and the same rule applies. The channel can follow the client's habits; the record stays in one place.

05Why does an approval trail matter?

An approval trail matters because most disputes on web projects are about what was agreed, not about the quality of the work. Recording who approved each draft, and when, settles those questions before they become arguments, and it protects the client as much as the studio.

It also helps inside the client's own organisation. In a school, a college or a firm with several partners, more than one person often has a say. The trail shows which person approved which page, so internal disagreements surface early rather than after launch. Admissions sites such as Aura, where a campaign page and a full college site share one voice, benefit from exactly this kind of clarity.

06How does logging help after launch?

After launch, requests arrive one at a time over months and years, which is exactly when memory fails. A single log with history makes maintenance faster, keeps security and update work visible, and gives you a record of every improvement made to the site.

Post-launch work typically includes:

• content updates such as new fees, dates, staff or services,
• security patches and platform updates,
• uptime monitoring alerts and backup checks,
• small improvements from search data or enquiry feedback,
• monthly notes on rankings, AI citations and enquiries.

Fig. 02Comparison

Requests in chat threads versus a portal

Scattered in chat and email:

• Requests buried in long threads
• Versions sent as attachments
• Approvals given in passing
• No single status view
• History depends on memory

Logged in a portal:

• One record per request
• One review link per draft
• Approvals recorded with names
• Status visible to both sides
• Full change history

This is part of how our websites and platforms and digital infrastructure work runs. It also connects to how we plan, which is described in the one-page website brief: the plan defines what was agreed, and the log shows how it was delivered.

07How do you write a good website request?

A good request names the page, says what should change and why, includes the exact wording or files, states how urgent it is, and names who will approve the result. A link and a screenshot remove most ambiguity. Clear requests are done faster and checked more easily.

A simple format that works for most clients:

1. Where. The page address, and the section if it is a long page.
2. What. The change, in a sentence. "Replace the 2025 fee table with the attached 2026 table."
3. Why. The reason, so the studio can suggest a better approach if there is one.
4. Materials. Final wording, images or documents, attached once.
5. When. A real deadline, or "no rush".
6. Who approves. One name.

The "why" is the part most often left out, and the most useful. A request to "make the button bigger" might really be a concern that mobile visitors are missing the enquiry form. Knowing that, the studio can check the form itself, the speed of the page and the wording around it, rather than only resizing a button. Logging the reason turns a small task into a decision that can be tested.

08Is this the same idea as building on intent?

Yes. Building on intent means deciding first, then building, and keeping a record of the decisions. A logged request is a small decision written down. A signed plan is a large one. Both exist so that the work answers to what was agreed, not to whoever spoke last.

Our article on what built on intent means explains the wider idea.

09What to do next

Look back at the last five changes made to your website. For each, try to find who asked for it, when, and who approved the result. If that took more than a few minutes, or turned up a disagreement, your requests need a log.

Book a call and we will show you how a project or maintenance retainer runs through the portal.