Skip to content

Web & Digital Platforms

Web applications: one job, every role, in step

Today the office texts the technician, the technician calls the office, and the customer calls both to ask what's happening. A web application puts everyone on the same job. Each person signs in, sees what their role allows and does what they're allowed to, and a change made by one shows up for the others straight away. We build it around the roles that share the job, connected to the systems you run.
Talk through your applicationSee who sees what ↓
office · coordinatorT3 · technicianJ.H. · customerTodayJ-641T1doneJ-644T3scheduleden routeJ-646T14scheduledextra work approvedcan: assign · rescheduleJ-644J.H. · no heaten routeadd photosquote extra workigniter · quote sentapproved · go aheadcan: en route · photos · quoteYour visitTue 8–10scheduledT3 is on the wayextra workreplace igniterApproveapprovedcan: approve · reschedule

Who sees what

One application; what each person sees and can do comes from their role.
Coordinatorevery job today, by technicianassign, reschedule, message
Techniciantheir own jobs, with directions and historymark en route, add photos, quote extra work, close out
Customertheir own visit and its statusapprove extra work, reschedule within the rules
Ownereverything, including moneychange prices and roles

What's inside a web application

  1. 01

    Sign-in and roles

    Who someone is decides what they see

    Staff and customers sign in the same way; their role sets their screens and actions.

  2. 02

    Live updates

    Changes show for everyone at once

    When T3 taps en route, the office and the customer see it without refreshing.

  3. 03

    Every state designed

    Loading, offline, failed

    The app always says what's happening and what the person can do next.

  4. 04

    Permissions on the server

    Not just hidden buttons

    The server checks every action, so a hidden button can't be worked around.

  5. 05

    History

    Who did what, and when

    Every change is kept with who made it, for the office and for disputes.

Three hard moments

The everyday case is easy. These are the ones the design is for.

Two edits at once

What happens
the coordinator reschedules J-644 while T3 marks it en route
The app
keeps both changes and tells the coordinator that T3 is already on the way
Nobody
loses work

The parts it's built from

Each part is built and tested on its own, so you can start with one and add the rest.

  1. Structure

    UX & Information Architecture

    Screens from each role's day.

  2. Screens

    Application Frontends

    • role
    • job state
    • connection

    offline → changes kept on the device

  3. Services

    Backend Architecture

    Rules and records on the server.

  4. Quality

    Web Performance · Accessibility

    Fast on a phone, usable by keyboard.

Sign-in and rolesIdentity & Access ManagementWho each person is, and what they may do.

Is a web application the right system?

Good fit

  • Several kinds of people work on the same records.
  • Work happens on phones as well as at desks.
  • Today it's held together by texts, calls and a spreadsheet.

Avoid when

  • One team, one job, one spreadsheet. Look at an internal tool.
  • Customers only need to see their own account. Look at a customer platform.

How we'd approach it

Most of the early work is mapping the roles, what each may see and do, and the moments where a change has to reach everyone.

  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 web applications

A web app or a phone app?

A web app that works well on phones covers most needs and opens from a link. A phone app is worth it for heavy offline use or device features like scanning.

Can customers and staff really use the same app?

Yes. They sign in to the same application, and each sees only what their role allows. The server checks every action.

What happens when the connection drops?

Changes are kept on the device and sent when it returns, and the screen shows what hasn't been sent yet.

Who owns it?

You do: the code, the data and the accounts. You can run it yourself, with another developer, or with support from us.

Put everyone on the same job

Tell us how the office, the field and customers keep each other informed today. We'll show you what one shared application would change.

Start a project