01 / Portals

Customer portal development starts with who can see what.

Permissioned customer and staff interfaces for records, actions and workflows that should not be public by accident.

The offer is a defined portal interface. It is not a claim that Tervuq already hosts a product or owns an existing customer system.

Roles and connections set the quote basis

A portal permission matrix with selected and unselected access cells — Illustrative role-permission study. It is not a deployed hosted product.

Roles / records / actions

Authorization is more than a hidden menu.

A client portal development project has to answer a harder question than “where does the user click?” It has to say which account may read a record, which role may change it, and what the interface says when the answer is no.

Customers may need to check their own request without seeing anyone else's records. Staff may need to review assigned work without changing account permissions. Both views depend on checks against the system that owns the record, not just the controls visible on screen.

Discuss a request

02 / Commercial basis

Agree the roles before the estimate.

Tervuq gives a scope-based estimate in USD after inquiry. The quote basis is agreed roles, workflows and connections to existing systems, not a numerical starting price.

A submitted inquiry is not an order. The work cannot be priced honestly while “customer,” “staff” and “administrator” remain loose labels with no record boundary.

Catalogue item / Customer portals

Customer and staff account interfaces with explicit boundaries around who can see a record and who can act on it.

Scope-based estimate in USD after inquiry

What the estimate needs to account for
Roles	Named account types and the records, fields and actions each role can access.
Workflows	Invitation, acceptance, recovery, review, change and closure states, including the states that stop an action.
System connections	Existing sources of records, identity services or operational systems that the interface must read from or update.
Authorization boundary	Checks that remain true even when someone guesses a URL or submits a request outside the visible navigation.

03 / Catalogue

Two portal jobs. Neither is a public website.

These are catalogue descriptions for scoping a conversation, not claims about a hosted product or existing delivery history.

A / Customer portal

Give a customer the right record and the next useful action.

A customer portal can present an account overview, selected records, status changes or a request route. It suits a business where customers need a place to inspect or act on information that should not appear on a public website.

Made of	Role-aware views, invitation and recovery states, record summaries and explicit action feedback.
Suits	A customer workflow with a known record boundary and an existing system connection to discuss.
Basis	Agreed roles, workflows and system connections. Scope-based estimate in USD after inquiry.

B / Staff portal

Keep internal records useful without making every account an administrator.

A staff portal can expose the work a role needs without presenting every control to every person. It suits a team that needs account visibility, approvals or record actions with a clear authorization boundary.

Made of	Staff role views, queue or record access, state changes, validation and messages for denied actions.
Suits	An internal workflow where the source system, responsibility and failure states can be described.
Basis	Agreed roles, workflows and system connections. Scope-based estimate in USD after inquiry.

04 / Account states

The forgotten states are the ones people call support about.

An invitation that cannot be accepted, a recovery email that never arrives or a record that disappears after a role change needs a defined response.

Invitation and acceptance.

An invitation needs an owner, an expiry rule and a clear acceptance state. It should not quietly create an account with more access than the invited role permits.

The screen can explain the next step without displaying the invitation token or a private record. An expired link needs a route to request another invitation. An already-used link should not create a second account. Agree who may resend an invitation and how a revoked invitation is rejected.

Recovery without disclosure.

Recovery needs a useful message whether the account exists or not. It should not reveal a private account merely because someone typed an email address into a form.

Scope questions cover the identity connection and the recovery responsibilities rather than pretending the interface owns every account service.

Records with a boundary.

A role is not a label painted on the interface. The permission check must apply to the record request and the action request. A hidden button is not authorization.

If a record cannot be shown, the user needs a readable state and a route to ask about the workflow, not a blank panel.

05 / Visibility model

Write down the answer before drawing the table.

A simple matrix is often more useful than a screenshot. It forces the scope to name the role, object and action.

Illustrative permission questions for a portal scope
Role	Record	Read	Change	Failure state
Customer	Own account record	AllowedShow the relevant fields.	AgreedOnly where the workflow permits it.	Explain the unavailable action.
Staff role	Assigned work record	Role checkDo not infer from a menu.	Role checkValidate the transition.	Keep the record state visible.
Administrator	Configuration record	ExplicitScope the responsibility.	ExplicitReview destructive actions.	Require a useful confirmation.

06 / A direct answer

Who is this for?

It is for a business that has a real role and record problem: customers need access to their own information, or staff need a controlled working view. It suits a team prepared to discuss the system connections behind the interface.

It is not for someone seeking a login added to a public website without deciding what that login protects. It is not a claim of an existing hosted product, a security certification or an automatic answer to every authorization problem.

Internal business tools may be the better route when the users are staff and the work is primarily a queue or task sequence. A public website may be the better route when no account is needed. Tervuq will say which distinction affects the scope.

Compare internal business tools

07 / Start with the boundary

Tell us who needs to see what.

Name the roles, record types and action that needs to be controlled. Do not include passwords or confidential client records.

Tervuq / portalsRole before polish
Record before menu