Dubsado client portal example: one video project, page by page

A Dubsado client portal is not one screen. It is a set of linked pages a client reaches through a single login: an intake form, a contract, an invoice, a booking page, and a project area that holds files and messages. The useful question is not what those pages are called, but whether that set of pages carries a whole creative project from enquiry to final payment without the work leaking back into email.

Below is a worked example of that portal on one brand film, page by page, followed by the point where it stops holding up on video and how to decide what to do about it.

What the portal covers, surface by surface

Four client-facing surfaces do most of the work in this kind of tool:

• Forms collect structured input — an enquiry, a project brief, a change request — and the answers land in a client record instead of a mailbox.
• Contracts and proposals are presented as a page the client signs in the browser, which removes the print-sign-scan loop.
• Scheduling gives the client booking slots so kickoff and review calls are set without a thread of proposed times.
• Invoicing issues deposits and finals, usually triggered by a status change rather than a reminder you write yourself.

Behind those sits a workflow engine: contract signed triggers project creation, a deposit invoice and a kickoff link; a stage change triggers the next task or email. All of this is client lifecycle — enquiry through payment. None of it is production. That distinction is the one that decides whether you need a second tool, and it is worth holding onto for the rest of this article. If you want the wider landscape first, our comparison of client portal software for agencies covers how different tools divide those two jobs.

Worked example: one 90-second brand film, page by page

Northline Coffee commissions a 90-second brand film from a two-person studio. The client is the marketing lead; the studio's editor is freelance. Here is what Northline sees, in order.

1. The enquiry form. Fields: company, project type, budget band, target deadline, who signs off on the final cut, and links to three reference films. On submit, a workflow creates the lead record and sends an automatic reply with a booking link.
2. The proposal page. Scope, deliverables, two revision rounds, delivery date. The client reads it, signs the contract in-page, and the same workflow issues a deposit invoice with a due date. In the studio's account, a project is created with a kickoff task assigned to the producer.
3. The project area. The client sees a checklist of stages — Kickoff, Script, Shoot, Rough cut, Review, Final — plus a shared file area, a booking link for the kickoff call, and a message thread on the project.
4. Draft delivery. The studio uploads the rough cut to the project file area, moves the stage to Review, and a notification goes out. The client opens the file, watches it, then types feedback into a text box or replies by email: “the second half feels slow and the logo lands late, can we tighten it?”
5. Approval and final invoice. The client approves the cut or signs a sign-off document. The final invoice issues from that status change, and the deposit is credited against it.

Read that list again as a lifecycle. It is complete, and it is genuinely less admin than email plus a shared spreadsheet plus a separate invoicing tool. Steps 1, 2, 3 and 5 are things the portal does better than any improvised alternative.

Step 4 is where the example gets thin, and it is the step creative teams spend most of their time in.

Where the example breaks: review precision and file versions

Two seams show up on video work, and both appear in step 4.

Feedback has no coordinates. “The logo lands late” is a sentence, not a location. With one reviewer working on a 30-second clip, your editor can find it. With three reviewers on a six-minute film, you get three prose descriptions of three different moments, and the editor scrubs to find each one before deciding whether the notes conflict. Nothing in the portal forces a note onto a specific frame or second.

Comments and versions drift apart. The studio uploads cut v2 to the same file area. The thread where the client described the slow section still sits there, unlabelled, and after two rounds nobody can say with confidence which comment applied to which cut. Whether your file area keeps a named version stack a client can switch between, and how large a file it will accept, is a plan-level detail worth testing rather than assuming.

Put an illustrative number on the first seam, and treat it as an arithmetic model rather than a benchmark. Say you finish 20 videos a year, each with 3 client review rounds and 2 reviewers per round. If a round of untimed feedback costs the editor an extra 30 minutes of clarification, scrubbing and rebuilding the change list, that is 20 × 3 × 0.5 = 30 hours a year. Substitute your own counts — the multiplier is the point, not the figure.

The kloudboard review layer is where the right-hand column comes from: timestamped comments and @mentions on videos and documents, opened from a card's Review action, plus file version history where a new upload keeps the old ones available. The mechanics are in how to use Review and in approval workflows with file version history.

Which setup to pick: three questions, asked in order

1. How many reviewers and rounds does a typical deliverable have? One reviewer, one round, short asset: portal comments are enough and adding a second tool is overhead you will not pay back. Three or more reviewers, two or more rounds, anything over a few minutes long: untimed feedback costs more than the tool.

2. Does sign-off need to point at something specific? “Approved” against a project is fine for a social clip. If a brand team needs to be able to say later that version 4 of the film was approved on a given date, your approval record has to name the version, not just the project.

3. Who else touches production? Freelance editors and contractors need access to the cut without seeing rates, contracts or the rest of the client roster. In kloudboard, guests do not count as paid seats, and a guest without the view-all permission sees only the cards they are assigned — the setup steps are in giving clients project access without exposing internal work.

The honest tradeoff of the split stack: the client still sees one portal, but you maintain the project in two places. A new job is created in the CRM and again on the board, and stage changes are updated by hand unless you automate them. That is real, recurring work, and it is the cost you weigh against the review hours. The all-in-one route removes the double entry and adds a migration; the split route removes the review friction and adds admin. Neither is free.

Run the pilot on one live project

Run one live project through both layers

Use a real project in review to find the exact step your client portal cannot carry, so the buy-or-pair decision rests on evidence rather than a demo.

A pass is not “the client liked it.” A pass means the client approved a named version, the editor could act on every note without asking a clarifying question, and the invoice went out from the same place the work lived. If any of those three broke, you have located the layer to replace, and you can run the next project with the fix in place before deciding anything permanent.

What to verify before you commit either way

• Seat and guest model. Check the current pricing page for both tools, and confirm whether client reviewers and freelance editors consume paid seats. Seat maths changes the decision more often than features do; our guide to free client seats versus paid user seats walks through the roster audit.
• Storage and file limits. Camera masters are measured in gigabytes. Test with a real 4–8 GB export, not a trailer.
• Version behaviour. Upload the same file twice and confirm you can still open the first version and see which notes were made against it.
• Scoped client access. Confirm what a client sees when a card is not assigned to them, and test it before the client does. The step-by-step version is in setting up a client project portal that shows only their work.
• Export and offboarding. Know how to get your client records and files out before you put a year of work in.

Do the pilot on the project already sitting in review, not a synthetic test file — a demo hides exactly the ambiguity you are trying to find. Whichever way the three checks land, you will have the answer on one live job rather than at the end of a migration.