Which customer approvals belong in a client portal?

Start with a decision that changes the work

A portal earns its place when your team repeatedly has to reconstruct what somebody agreed. Perhaps a drawing changed after the client replied, or a colleague treated an encouraging comment as permission to place an order. The useful starting point is the decision that went missing.

Design sign-off, agreement to a revised specification and permission to publish a finished asset can each justify a recorded approval. A passing preference about a colour probably belongs in feedback until the team has turned it into something concrete to review.

You don’t have to move every conversation into a new system. For occasional, straightforward work, an organised email exchange may be enough. A portal becomes more useful when several people contribute, versions change frequently or the same approval step recurs across projects.

Make the approval specific

Consider a fictional interiors studio reviewing a fitted-cabinet design. 'Approve project' asks too much. 'Approve cabinet layout, revision 4' identifies a decision the customer can actually examine, especially when the screen explains which drawing and specification belong to that revision.

The request should say what approval allows the team to do. Layout approval might allow detailed drawings to start while leaving finishes unresolved. If approval will trigger an order or another commitment, explain that before the customer acts and make sure it matches the actual agreement.

Keep the review material available alongside the request. A customer shouldn’t have to guess whether an attachment downloaded last week is still the version on screen. Give the decision a clear boundary.

Let customers request changes without approving

'Approved, apart from the dimensions' is an awkward status for a team about to build something. Give people an explicit route to request changes. The project can then stay in review until the revised material is ready.

Comments should stay attached to the version they concern. When a new revision replaces it, preserve the earlier discussion and show which request is current. Don’t quietly transfer an old approval onto a different document.

Decide what happens when a customer spots a mistake after approving. A correction request can alert the responsible person and pause the affected next step where appropriate. The earlier decision should remain understandable, with the later change recorded against it.

Keep a decision record people can understand

A useful business record identifies the reviewed item and revision, the person who acted, when they acted and the outcome. Include the wording they agreed to where it defines the permission being given. A status label without that context leaves the next person asking the same questions again.

OWASP’s logging guidance recommends recording the time, location, actor and action of application events. That is security guidance, rather than a ready-made customer approval specification. We use it here as a useful prompt for deciding what a business needs to trace. The approval record and the technical security logs may serve different readers.

Agree how long these records need to remain available, who may read them and how the business can retrieve them when a project closes. Avoid collecting unrelated personal detail just because the system could store it.

Source: OWASP: Logging Cheat Sheet

Give the right person permission to act

Someone may need to read drawings without having authority to approve them. Agree the customer’s decision-maker and how a replacement is appointed if that person leaves or is unavailable. A shared login makes it harder to attribute an action to an individual.

OWASP distinguishes signing in from permission to perform a particular action. Its guidance recommends checking permissions on every request and granting only the access a person needs. For a portal brief, ask for approval permissions to be enforced by the application, including checks that one customer cannot act on another customer’s project. Hiding a button isn’t enough.

Source: OWASP: Authorization Cheat Sheet

Show what happens after the click

Once the decision has been saved, show which revision was approved and what the team will do next. GOV.UK’s confirmation-page guidance recommends telling users what happens next and when, with a way to save a record. Those principles are useful in a customer workspace too.

Only show success after the application has actually recorded the decision. A failed connection should leave a clear explanation and a safe way to check or retry. Repeated clicks shouldn’t create conflicting approvals or trigger the next stage twice.

Before launch, walk through the awkward cases with the people building the portal: an outdated review link, a failed save, a withdrawn approver and a revision issued while somebody is reading. These are practical acceptance checks for the agreed workflow.

Source: GOV.UK Design System: confirmation pages

Bring us the handover that keeps going wrong

Pointed builds bespoke customer portals and internal tools around an agreed specification. Show us one recurring approval: what the customer reviews, who decides and what your team does afterwards. We can help turn those rules into a useful workspace, with access, integrations and ongoing responsibilities scoped before the build.

Use an anonymised example for the first conversation. This guide concerns operational review workflows; specialist signature or regulated approval requirements need their own assessment before the system is specified.

Enquire by email, WhatsApp or our short enquiry form. We agree the scope and price with you before you pay by Stripe invoice.

Read what belongs in a client portal