What can the client actually see?
Review fields such as the title, description, status and target date of a work item. Keep internal notes separate. Use the client account or sharing view to check exactly what is exposed.
HOKUSH / Client portal selection guide
Choosing a client portal: what should your team and clients check?
Before choosing a client portal, define which work, files and conversations the client should access. Then test that scope with a real example rather than making a decision from a feature list alone.
What should you look for in a client portal?
Work and file visibility, access permissions, the feedback channel, link expiry and access revocation are core selection criteria. Evaluate workspace access for ongoing client work separately from a work-sharing link for a single delivery.
Six questions to answer in a demo
Can you choose individual files?
Try a draft and a delivery file. Check that the client can see the correct file and cannot see source files you did not share. Clarify the version to review in the filename and work description.
Where does feedback go?
If the client needs to comment, try the conversation. If you only need to present information, evaluate the option to turn the conversation off. Build a workflow that keeps feedback connected to the relevant work.
When does access end?
Test time-limited links and revocation in the demo. Revoking access does not retrieve a file already downloaded; ending access and deleting a file are separate actions.
Are ownership and delivery expectations clear?
Record who follows up, the target date and the decision expected from the client. Agree whether a comment means delivery acceptance or a request for another revision.
Does it fit real usage conditions?
Try the example workflow on the phone and computer your client uses. Compare language, required account steps, file capacity, plan scope and support terms with current product information.
Try one design job
Prepare a draft campaign visual. Share only the draft file and the feedback you need. Keep the internal discussion private. Ask the client for one round of feedback on the headline and visual choice, then present the correct delivery file and review whether the link is still needed.
A decision note template
Example work item: Client access method: Fields that should be visible: Files and versions to share: Information that should stay private: Feedback owner: Conversation on / off: Target date and acceptance criteria: Link expiry / revocation owner: Observed results on phone and computer: Open questions about plans / language / support:
How can you evaluate these criteria in Hokush?
Client workspace access in Hokush depends on roles and permissions. For external sharing of a specific job, you can select fields and files, set conversation permission and link expiry, and revoke the share. Evaluate these two access methods separately. Revocation does not retrieve files already downloaded. The team and client clarify revision scope and delivery decisions.
Client portal and job sharingCommon selection questions
Is a file link the same as a client portal?
A file link may present a particular file. A client portal can also bring permitted work information and communication together. Test the actual scope in the product’s client view.
Does the client need access to the whole team workspace?
Not for every job. Separate ongoing access from a share for one work item, and expose only the information the work requires.
Does “looks good” in a conversation automatically approve delivery?
Agree in advance what counts as acceptance. This guide does not claim that Hokush offers a separate automatic approval or file-version comparison feature.
A source for access scope
OWASP recommends limiting access to the minimum scope needed to do the work. The demo questions apply that principle to product selection; they are not a security certification or a product security audit.
OWASP Authorization Cheat SheetContent reviewed: