Moving equipment management from the phone into the product

Client: Paysafe
Role: Senior Product Designer
Year: 2025
Tags: Desktop, Product strategy, UX, UI

Paysafe, a global leader in payments, was running a flagship transformation programme to simplify a complex merchant onboarding and servicing landscape. I led design on the Equipment Lifecycle Management workstream: how merchants order, receive, set up and manage their payment terminals. Before this work, none of that existed in the product. Equipment lived on the phone.

Problem

Equipment management was a phone process, not a product

Merchants used Optic, Paysafe's merchant portal, for their account. But equipment wasn't in it. Terminals were agreed with a sales agent, ordered by an agent and every question afterwards, where is my order, how do I set this up, I need to change something, went through customer support.

No visibility, no control

Merchants had no way to see what they had ordered, track it, or act on it independently. The portal they logged into simply didn't cover the thing they had bought.

Support absorbed the entire lifecycle

Contact volumes were high because support wasn't a fallback for equipment. It was the only channel.

Reducing contact was the goal

Bringing those contacts down was an explicit goal of the workstream, not a side benefit.

The equipment lifecycle: shop, checkout, track, receive and manage built into Optic, with exceptions staying with customer support — Nothing below the line existed before this work. Every stage was designed and built in this workstream.

Role

Strategy, UX and UI for the workstream

I owned strategy, UX and UI: working with stakeholders to understand business goals and technical constraints, defining scope alongside engineering, designing the end-to-end journeys and producing delivery-ready detail for the teams building it.

Approach

Designing against moving constraints

Discovery

Running discovery in parallel with requirements

Discovery ran alongside requirements gathering rather than ahead of it. With a 60 day window to show value, design decisions and technical decisions had to inform each other in real time rather than arriving weeks apart.

Alignment

A working group to hold the scope steady

Limitations weren't fixed at the outset and the goalposts moved often. That is a normal condition on a transformation programme, but a difficult one to design against. I set up a working group with the decision-makers who could actually resolve it: Product Manager, Delivery Lead, front-end and back-end engineers, Product Platform Lead and the VP of Customer Support.

Having support in the room mattered. The person who owned the call volumes we were trying to reduce was present when scope was set, which kept the design pointed at the journeys generating the most contact rather than the ones easiest to build.

Trade-off

Committing to the spine, deferring the branches

With constraints still shifting, I scoped the proof of concept to the core path, processing through shipped to delivered and deliberately left exceptions with customer support for a later phase.

This was the central trade-off of the project. Designing every failure state on an unstable foundation risked building the wrong thing twice. Designing the spine first meant merchants could self-serve the routine majority of equipment interactions, while the harder edge cases stayed on a channel that already handled them. It is a first cut, not a finished product and it was chosen as such.

Solution

From an agreed order through to living with it

Phase one brought an agent-agreed order into the product: complete the purchase, track it, receive it, manage it. Phase two, designed but not built during my engagement, added a route to buy more without going back to an agent.

Acquiring

Completing an agreed order

Adding a payment method before approval was the hardest problem in phase one. Equipment was agreed with a sales agent outside Optic. The merchant then logged in, found their agreed equipment on the Terminals page and added a payment method to complete the order, all before their application had been approved.

That meant asking for payment details against equipment that hadn't been approved, wouldn't be charged yet and had been chosen in a conversation that happened somewhere else.

The Terminals page before approval, prompting the merchant to add a payment method alongside their agreed order summary — The pre-approval state: equipment agreed with a sales agent, shown before the merchant owns it.

The confirmation had to resolve all three uncertainties at once: what would happen, when and what would appear here afterwards.

Your equipment order is set up. Your selected payment method will be charged for your equipment order once your application is approved. Your terminals and order history will be available to view here once your application has been approved and your order has been processed.

The confirmation state explaining when the payment method will be charged and what will appear on the page afterwards — The confirmation answers what happens next and when.

The same task in a settled state, with an application already approved, dropped the deferred-charge explanation. The Terminals page therefore had to hold two distinct realities: a promise of equipment and actual equipment.

Tracking

Order states and history

Orders moved through processing, shipped and delivered, with an orders tab and order detail behind each one, available once an application was approved and the order processed.

The Orders tab listing order number, items, total and the date the order was placed — Order history: the answer to what did I order, without a phone call.

Order detail showing the processing state — Three states, one view: the order tracking that replaced 'where is my order' calls.

Order detail showing the shipped state — Three states, one view: the order tracking that replaced 'where is my order' calls.

Living with it

Terminals and setup documentation

Delivered terminals appeared in their own tab, each with its setup documentation attached and a record for every piece of equipment.

Setup documentation is where the self-service goal became concrete. "How do I set this up" was a support call. Putting the documentation beside the terminal it belonged to removed the reason to make it.

The empty Terminals tab, explaining that terminals appear once they have been delivered — Documentation placed beside the equipment it belongs to, removing the reason to call.

Delivered terminals listed as ready for setup, each with a link to its documentation — Documentation placed beside the equipment it belongs to, removing the reason to call.

Unwinding

Cancelling an order

Cancellation stayed available for as long as the merchant hadn't entered payment details. Tying the cut-off to payment entry rather than a time window or a fulfilment stage meant the rule was knowable from what the merchant could already see. No live-looking button that had quietly expired.

The flow offered recovery before confirmation, then captured a reason:

Are you sure? If you want to speak to a sales agent about amending your order, contact support. Cancelling your order means that you won't receive the equipment that you chose with the Paysafe sales agent.

Reasons were operational rather than a satisfaction survey: I don't need equipment anymore, I already have equipment, it's too expensive, I ordered the wrong items, plus free text. Each routes to a different response. The merchant who ordered the wrong items needs a different follow-up from the one who found it too expensive.

The prototype: cancellation offers amendment before it accepts the decision, then captures a reason that routes to a fix.

Phase two

Buying without an agent

Phase one still depended on a sales agent to originate an order. A merchant who simply wanted another terminal had to call.

I designed a shop and checkout to close that gap: browsing terminals and accessories and buying them directly in Optic. It was deliberately additive rather than a replacement. The agent route stayed for new merchants and complex configurations, while existing merchants could reorder on their own. Once purchased, the equipment rejoined the phase one journey at tracking.

This work was designed and specified but not built during my engagement. It is included here because the design resolved a real limitation in phase one, not because it shipped.

A terminal product page showing what is in the box, add-on accessories and technical specifications — Phase two: a reorder route for merchants who already had equipment and wanted more.

Outcome

Equipment moved into the product for the first time

32%

Fewer support contacts

Equipment-related contacts fell by nearly a third, the workstream's primary business goal, measured on the phase one release.

60 days

To measurable value

Value delivered inside the programme's window, without trading away quality.

Alongside those numbers, the workstream delivered:

A product roadmap and delivery backlog defined for the entire Equipment Lifecycle Management workstream
Target architecture validated through a steel-thread proof of concept
A significant shift towards merchant self-service
A production-ready Angular application delivered into the transformation programme

Each reason merchants called mapped to what now answers it: order status, setup guides and the cancellation flow moved into the product, while amending an order and changing a payment method remained with support — Three call drivers answered by the product. Two left with support, deliberately.

Reflection

The spine works, the exceptions don't yet

A merchant whose delivery is delayed is back on the phone and the merchant who wants to change their payment method before approval is told to contact support, a self-service gap sitting inside a self-service project. Both were deliberate calls given the timeframe and the shifting constraints and both are the first things I would take into a second phase.

The decision I would repeat is the working group. Getting the VP of Customer Support into the room where scope was decided did more for the outcome than any individual screen.