Knowledge · Customer Experience

    Customer Access and Authentication

    Portal access comes in two forms: an issued private link or a customer password account. Learn the trade-offs, and how to keep link-based access controlled.

    How do customers get into a client portal?

    Two models exist. A private access link issued by the business opens the portal with no password, which maximises adoption. A password account adds an identity check but adds friction. Link-based access stays safe only when links are per-customer, revocable and able to expire.

    Key takeaways

    • Issued links win on adoption; password accounts win on identity certainty.
    • With links, the link is the credential — treat it that way.
    • Per-customer, revocable and expirable are the three non-negotiables.
    • Never route a customer link through an internal login screen.
    • Log access so you can answer 'did they see it?' with a record, not a guess.

    The two models

    Issued-link access sends the customer a private URL that opens their portal directly. There is nothing to remember and nothing to reset, and adoption is dramatically higher — most homeowners will not create an account to check a roof date.

    Account access asks the customer to register and sign in. It proves who is on the other side more strongly, which matters when the portal exposes money movement or personal data beyond the job itself. It also loses a meaningful share of customers at the registration step.

    Making issued links safe

    • One link per customer — never a shared link that resolves by lookup.
    • The link is revocable: the business can switch it off at any moment.
    • The link can carry an expiry date so forgotten access closes itself.
    • The link exposes only that customer's scope, enforced on the server.
    • Access events are recorded so opens are visible internally.

    What access should never do

    • Grant the customer any view of another customer's work.
    • Reuse an internal staff login path for external people.
    • Depend on the browser to hide anything — scoping happens server-side.
    • Store the customer's identity claims in a way the page itself can change.

    Where URBLD fits

    URBLD's customer portal opens from an access link tied to a single customer record. The access record carries an active flag and an optional expiry, and the data returned is resolved server-side for that customer and organisation only. Contract signing uses a separate per-signer link.

    Principles reinforced

    This page rests on the following foundational ideas.

    FAQ

    Frequently Asked Questions

    Straight answers about how URBLD runs the business end-to-end.

    More in Customer Experience

    What customers actually judge: communication, clarity and reliability.

    Browse Customer Experience
    Share this page