Define what “approved” must mean

An agency discussion about client approvals describes requests and decisions split across email, Slack, WhatsApp, files, and project tools. Replies also describe workable configured processes and promote many products. The thread shows that the question exists. It does not show which process is best or that custom code solves it.

Turn “stop losing approvals” into an inspectable outcome. For each deliverable, the agency and client should be able to identify:

  • the exact version under review;
  • the person authorized to decide;
  • approve, reject, or request-changes outcome;
  • decision time and note;
  • the next owner and due date; and
  • the retained history after a revision.

That is the workflow. A portal is one possible interface.

Start with configured alternatives

Current documentation shows that established tools already represent important parts of the workflow.

Google Drive approvals documents approvers, due dates, file locking, approval reset when content changes, and prior approvals. Google also says the feature is limited to eligible Enterprise and Education Plus accounts.

Asana approvals documents approve, request-changes, and reject outcomes, as well as assignees, due dates, dependencies, fields, and rules. Its documentation notes that permission and plan details matter, including who can complete an approval and what happens if the plan changes.

Those are documented capabilities, not recommendations. They do not establish that a particular agency has the plan, configuration, client access, effective permissions, export, or continuity it needs.

Compare four bounded options:

Option Smallest useful shape Unresolved test
Email plus decision log One version link, named approver, explicit response format, staff-owned row Whether clients follow it and the history survives staff absence
Document approval Use an eligible existing file-approval feature External access, permissions, version behavior, export, and client friction
Project-tool approval Configure an approval task around the deliverable Guest access, decision authority, version binding, plan limits, and offboarding
Narrow custom layer Link trusted file storage to a decision record Every trust boundary plus operation, recovery, and provider replacement

No option wins from documentation alone.

Apply hard stops before scoring convenience

A failed hard stop blocks the custom build. It cannot be averaged against a clean interface or faster reminders.

Approver authority

Can the agency define who is allowed to bind the client to a decision? If the contract, project role, and operating process disagree, software will encode the ambiguity rather than solve it.

Do not treat a product approval click as a legal signature without qualified advice for the actual agreement and jurisdiction.

Version identity

Can a reviewer see the exact version they are approving? What happens when the file changes during review? Does the decision reset, remain attached to the old version, or silently appear current?

If a decision can move to another version without an explicit new review, stop.

Named identity and recovery

Can a shared account, forwarded link, or unmanaged recovery path approve work? Can the agency remove a departed client contact without losing the history?

Login is only one boundary. The system still needs authorization for the named deliverable, decision action, and client relationship.

Cross-client isolation

Could one client discover another client's file, comment, metadata, or approval history? A mistake here turns a small workflow helper into a serious multi- client system. Use an established tenant-aware system and obtain security review when the team cannot demonstrate isolation.

History and export

Can the agency produce the decision history after a dispute, staff departure, plan downgrade, or provider exit? If the record exists only in one person's inbox or a presentation layer that cannot be exported, the workflow is not durable.

Operational ownership

Who owns reminders, client access, support, retention, incidents, updates, and account recovery? If no named role accepts those responsibilities, follow the rule in No Operational Owner, No Custom App: do not build.

Run the same packet through two alternatives

Freeze one non-sensitive test packet:

  • one sample PDF or image;
  • v1 followed by a visible v2;
  • one named test-client approver;
  • request changes on v1 and approve v2;
  • one due date; and
  • one staff-owned export or decision register.

Run it through email plus the decision log and one eligible configured approval tool. If the agency already has a project platform, test its approval path as a third option.

Record:

Criterion Observation
Named identity required
Exact version visible
v1 decision preserved after v2
Another test-client account denied
Request-changes note retained
Reminder and due date visible
Client completes without staff impersonation
Decision history exports
Staff owner can be replaced
Plan, guest, and permission limits recorded

This article's evidence packet preserves that protocol, but no agency tenant or client account was configured for publication. The evidence supports configure and test, not product suitability.

Choose the smallest defensible outcome

For a synthetic eight-person creative agency with one named approver per deliverable, the current decision is:

Configure and test. Do not build a portal merely because email loses context.

Choose configure when an existing option meets the outcome with acceptable friction and continuity. Consider a narrow custom layer only for a distinct gap that can reuse trusted identity and file storage. Choose do not build when approver authority, isolation, recovery, history, or operational ownership has no accountable owner.

This follows the broader principle in Build the Workflow Layer, Not a New System of Record: do not replace trusted storage or identity just to add a clearer decision state.

Revisit the custom option only with evidence

Revisit when:

  • several approval types require repeatable routing configured tools cannot represent;
  • a tested client experience produces a specific consequential failure;
  • identity, version, history, export, and continuity requirements are known;
  • a named operator can support the system; and
  • custom scope can avoid replacing file storage, signing, and tenant identity.

“Clients ignore email” is a workflow signal. It is not a software architecture.

Frequently asked questions

Is a spreadsheet decision log enough?

It can be a useful control for a small workflow if version links, authority, access, ownership, and retention are explicit. Test it rather than assuming it will be followed.

Does Google Drive or Asana solve the problem?

Their documentation shows relevant mechanics. Suitability depends on the real plan, tenant settings, permissions, client experience, export, and operating requirements. This article did not test those environments.

When is custom software justified?

When a consequential, repeated gap survives configured alternatives and the team can own every trust, operation, recovery, and continuity boundary.

Should the portal store the deliverables too?

Usually test the narrower option first: keep files in a trusted existing system and add only the missing workflow state. Replacing storage expands scope and risk substantially.