Skip to content

Customer Operations

Self-service portal: answer “where's my technician?” before anyone calls

Most calls to the office are questions your systems already know the answer to: when are you coming, can I approve the extra work, can I have the invoice. A self-service portal shows each customer the job's real status and lets them approve, reschedule, pay and message from their phone, with every action landing in the systems you already run. We connect it to the systems you already run, so every action lands where it belongs.
Talk through your portalSee what customers can do ↓
J-544 · 9 Willow CtBookedFri 08:00–10:00TechnicianT3On the wayarriving about 08:45Arrived08:44Extra work Q-262replace shut-off valve · $180Approve✓ approvedINV-2263$310Pay✓ paid“Where's the technician?”status shows on the way“Do I need to approve the extra work?”approved in the portal“Can I get the invoice?”paid and downloaded

The phone rings with questions you can already answer

When are you coming? Is the technician on the way? Do you need me to approve that? Can you send the invoice again? Each call takes a few minutes, interrupts someone, and is about something already recorded in your scheduling, quoting or billing system.

A self-service portal puts that information where the customer can see it, from the same records your team uses, and lets them take the simple actions themselves. The office keeps the conversations that need a person.

Today, and with a portal

Today

  1. 01Customers call to ask when the technician will arrive.
  2. 02Extra work waits on site while someone phones the customer for approval.
  3. 03Invoices are re-sent by email on request.
  4. 04Rescheduling is a phone call, during office hours.

The office spends its day relaying information the systems already have.

With a portal

  1. 01Customers see the job's real status, live.
  2. 02Extra work is approved with one tap, with the quote attached.
  3. 03Invoices and documents are always there to download and pay.
  4. 04Rescheduling works inside your rules, any time.
  5. 05Messages to the office land on the job.

The office keeps the conversations that need a person.

What customers can do without calling

Every action uses the same records and rules as your team, so nothing has to be re-entered.

1 of 5: See where the job stands

J-544 · status

the customer
sees booked, assigned, on the way, arrived, done
behind the scenes
states come straight from dispatch and the technician's app
rules
only confirmed times are shown as confirmed

What stays with the office

Customers do it themselves

  • See status and documents
  • Approve quotes within your limit
  • Reschedule within your rules
  • Pay invoices
  • Message the office about a job

Goes to the office

  • Approvals above your limit
  • Changes close to the visit
  • Complaints and disputes
  • Anything about safety

Never in the portal

  • ✕ Prices you haven't quoted
  • ✕ Other customers' information
  • ✕ Technicians' personal details
  • ✕ Promises dispatch hasn't confirmed

What changes from one business to the next

What customers seeStatus steps, documents and history
What they can doApprove, reschedule, pay, message, and the limits on each
Who signs inHomeowners, tenants, property managers, billing contacts
Where it connectsScheduling, quoting, billing and job systems
How it looksYour name, your colours, your domain

A common starting point is a web app built with Next.js on your existing scheduling, quoting and billing systems through their APIs, with Supabase or PostgreSQL for portal accounts and permissions and your existing payment provider. These are starting candidates, not requirements.

Is a self-service portal the right fit?

Good fit

  • A good share of calls are about status, approvals, invoices or changes.
  • Jobs involve extra work or quotes that need the customer's approval.
  • Your systems hold reliable status you'd be happy to show customers.

Avoid when

  • Status lives in people's heads, not in a system. A portal would show the wrong thing.
  • Jobs are one short visit with nothing to approve or follow.

How we'd approach it

Most of the early work is agreeing what customers see, what they can do and who signs in.

  1. 01

    Understand

    As much as the problem needs

    We map how the work runs today: who does what, which systems hold the records, and where it breaks.

  2. 02

    Design

    Decided before it's built

    Ownership, rules, integrations and exceptions, agreed with you and written down with acceptance criteria.

  3. 03

    Build

    Connected to what you use

    We build the scoped system, connect it to the tools you already run, and test it on the cases that matter.

Related systems

The capabilities underneath

Questions about self-service portals

Will customers actually use it?

They use it when it answers the question they were about to call about, at the moment they have it. Links in the confirmation and on-the-way texts take them straight to their job, without a password.

Does it replace our phone line?

No. It takes the routine questions off the phone so the office has time for the calls that need a person.

Can property managers see all their units?

Yes. Roles decide what each person sees, so a property manager can follow every unit while a tenant sees only theirs.

What if our systems don't have an API?

Most scheduling, quoting and billing tools do. Where one doesn't, we look at exports, a sync, or whether that part belongs in the portal at all.

Answer the questions before they call

Tell us what customers call the office about most. We'll show you which of those a portal would answer.

Start a project