Skip to content

Custom Software

Customer portals: a set of permissions, not a website with a login

A tenant wants to know when the technician arrives. Their property manager wants every open job across twelve units and a quote to approve. The manager's accounts team only wants the invoice. A good portal shows each of them the same job differently, and every button they press updates the systems you already run.
TenantUnit 4BVisitThu 08:00–10:00 · T3Accesskey at the officeMessage the officeabout this jobRepair bookedFri 10:00–12:00Property managerAcme PropertiesUnits12 units · 2 open jobsQuote Q-251$1,120ApproveapprovedInvoice INV-2240$340Billing contactAcme PropertiesInvoice INV-2240$340PayOctober statementPDFJob notesnot shown

The login isn't the hard part

Portals usually fail in one of two ways. Everyone sees the same screen, so it's either too much for most people or too little for the ones who need it. Or the portal shows a status that's out of date, and customers call anyway.

Building one starts with the people: who they are, which records each may see, and which actions each may take. The portal reads and writes through your existing systems, so a status in the portal is the status, and an approval in the portal is the approval.

Five parts of a portal

  1. 01

    Sign-in

    Who is this?

    A one-time link, a code by text or a company login. Easy for customers, specific about who they are.

  2. 02

    Records

    What may they see?

    Their jobs, units, quotes and history, scoped by role and relationship, never by hiding things on the screen.

  3. 03

    Actions

    What may they do?

    Approve, reschedule, pay, request. Each one checked by the same rules your staff work under.

  4. 04

    Documents

    What can they keep?

    Quotes, invoices, reports and certificates, always the current version.

  5. 05

    Messages

    How do they reach you?

    One thread with the office, attached to the job, so nobody has to explain it again.

Same job, three people

Permissions follow the relationship. When the tenancy ends, so does the tenant's access.

Tenant · Unit 4B

can see
their visit time and technician, access instructions, messages about their unit
can do
reschedule within your rules, message the office
can't see
quotes, prices, other units

What a portal hands off

In

User
identity and role
Records
jobs, quotes, invoices
Rules
who sees and does what
Portal
sign in → scope → act

Out

Actions
approvals, payments, reschedules
Messages
to the office, on the job
Audit
who did what, when

Worth building when customers keep calling for the same things

Good fit

  • Customers call or email for status, documents or simple changes.
  • Different people on the customer's side need different views.
  • The records already exist in systems the portal can read and write.

Not the right fit

  • Most customers only ever need one email confirmation.
  • The underlying records are unreliable. A portal will show the mess to customers.

Questions about customer portals

Do customers need another password?

Usually not. A one-time link by email or a code by text works for most people; commercial accounts can sign in with their company login where it's available.

Can it show data from the systems we already use?

Yes. The portal reads and writes through integrations with your job, quoting and accounting systems. It isn't a second copy of your data to keep in step by hand.

Is it an app customers have to install?

No. It's a web app that works well on a phone, reached from a link in a text or email.

What happens when someone's access should end?

Access follows the records. End the tenancy or remove the contact in your system and their access ends with it.