Fortis Plus

Executive Summary

Fortis Plus is an MVP SaaS maintenance platform for enterprise field operations. Before this project started, team ran operations across multiple disconnected tools: Maintenance logs in one place, inventory in another, route planning done manually. Nothing talking to anything else. The goal: replace that scattered experience with a single coherent product where work orders, parts logistics, and asset intelligence live together.

My role covered discovery through delivery. I ran stakeholder and customer research, defined the core interaction patterns, and shaped the product strategy that moved the platform from passive monitoring to active decision support. I designed across three user roles, each with its own device context: operation managers on desktop and tablet, field technicians on desktop, tablet, and mobile, and asset owners on a dedicated mobile app.

The Context

Field operations at enterprise scale run on coordination. Parts need to be on the right truck. Work orders need to reach the right technician. Assets need servicing before they fail, not after.

Fortis Plus was managing all of that across multiple separate platforms. No single tool gave anyone the full picture. Technicians checked one system for work orders, another for parts, and handled routing manually. Managers toggled between screens to piece together information that should have lived in one place.

The product brief was clear: one interface that replaces all of it.

The design challenge was figuring out what that interface needed to do to actually be worth the switch, across roles that work in completely different environments.

The Challenge

Two things were breaking down before a technician ever left for a site. First, pre-inspection reports weren't visible in the system. That meant that the manager handling ordering parts didn’t have the full visibility and could make an error. Parts got missed.

Second, technicians had no access to preview the current status of the assigned task. Not the status, not the parts order, not whether everything was actually ready. They were communicated to drive to the facility, but frequently something from the order was missed. The visit got rescheduled. The asset stayed down. The failure wasn't one thing. It was a chain. Connecting those steps, report generation, parts ordering, and pre-departure confirmation, was the core problem the platform had to solve.

Discovery and Strategy

We ran two rounds of discovery. Ten stakeholder interviews covering technicians and managers. Then 100+ Asset Owners feedback collected through the support portal gave us volume and pattern.

Four findings drove every major design decision that followed.

Finding 1: Technicians needed departure confidence. The breakdown wasn't just missing parts. It was having no way to check before leaving. Technicians needed to see two things in one place: whether all required parts had been ordered, and how many were already loaded on the truck. With that information visible, they could make the call themselves. Without it, every departure was a guess.

Finding 2: Finding the right part to order was slower than it should have been. Asset documentation existed, but there was no proper search function inside it. If a manager needed to order a specific part during an asset review, they had to manually scan through documentation to locate the right part number. No search. No shortcut. Just time spent looking for something that should have taken seconds to find. That friction added up across every order, every day.

Finding 3: Customers already knew what they wanted. Portal feedback wasn't vague complaints. Customers named specific gaps: demand forecasting, and early warning when an asset was heading toward failure. They weren't asking for a cleaner interface. They wanted the system to think one step ahead of them, and they said so directly.

Where the Design Started

Early versions of the Work Order line item showed the job details: asset, job type, priority status. It looked complete. But in practice, technicians couldn't plan their day from it. They knew what needed doing. They didn't know how long it would take to get there.

Travel time was the missing piece. Once it appeared at the line item level, the whole picture changed. Technicians could sequence their day by actual time available, not by gut feel. A job two hours away got weighed differently than one twenty minutes out. For sites beyond the two-hour mark, technicians could choose a remote video inspection instead of a physical visit, saving the trip entirely.

One field added. The entire planning dynamic shifted.

The Solution and key deliverables

Work orders with travel context built in. Desktop. Every work order shows travel time at the line item level. Technicians see their weekly route with job priority, asset history, and parts availability in one view. The call to go in person or inspect remotely is visible before they leave the building.

Parts order status and truck inventory. Desktop. Technicians have full visibility on which parts have been ordered and how many are already loaded on the truck. They make the final call themselves, with the information they need in one place, before scheduling the site visit.

Asset documentation with integrated part search. Desktop and tablet. Each asset record carries its full documentation set, searchable by part number through an AI-assisted search tool. A manager reviewing an asset can find any part, check live inventory status, and raise an order without leaving the screen. The workflow that used to span three systems now lives in one place.

Asset owner mobile app. Client-side managers aren't sitting at a desk waiting for updates. They're on the floor, in meetings, moving. The mobile app surfaces the two things portal interviews kept surfacing: visibility into asset health before failure happens, and demand forecasting so teams can plan ahead. Decision-relevant information only, no operational noise that belongs to the internal team.

Shared status language across all roles. Multiple platforms meant multiple ways to describe the same states. A shared priority taxonomy means a technician, a manager, and a client are all reading the same thing and responding to the same information, regardless of which device they're on.

‍