Payment Claims
Fergus - Payment Claims
Progress payments for long duration projects.

Payment Claims is essentially the ability to partially invoice a job. With large scale jobs like construction, piping of large buildings, excavations etc, payments are made throughout the course of the jobs duration so that the trades companies can maintain a stable income and also for the customers assurance that the work is being done properly.
There is a specific process that a Payment Claim must go through: The job must first be quoted at which point at various points of the works duration the trades company will create a Payment Claim from the original quote to ‘claim’ the cost of materials or labour that have already been done. A Payment Claim is created that lists the costs that the trades company wishes to claim and it is sent to the customer. The customer then has the chance dispute any costs on the Payment Claim, this dispute is settled over the phone, email or in person and once the dispute is settled the claim is paid and work progresses as normal.
One of our many whiteboard sessions
The initial workflow for Payment Claims
We talked to a few larger trades companies that had a use for Payment Claims, some who used Fergus and also some who didn’t, to find where Payment Claims might be able to fit into the current workflow of our software. The companies who talked to us told us their current method of creating claims and a lot of them were forced to export quotes & invoices out of our system (or whatever system they were using) into Excel and manually decide which and how much of each item they wanted to claim, then manually re-enter that information into their chosen system.
Our first UX challenge was to create a way for our users to use their quote created in Fergus and bring it through the entire Payment Claims within Fergus and ultimately send it out as an invoice to their customers. Essentially streamlining their actions.
The processes that occur before (quoting) and the processes after (invoicing) were already in place in the system. So we needed a system that would fit smoothly in-between quoting and invoicing to be able to accomodate existing Payment Claims processes. We needed a way for users to import their quote into a Payment Claim, edit their claim, send it to the customer, resolve any disputes if any were made and then convert the claim in to an invoice to send out for payment.

Desktop workflow for our first payment claims prototype
We used our newly implemented component library to prepare a user testing prototype after our initial whiteboard sessions. One of our UX challenges was making sure Payment Claims was also recognisable as a part of our workflow. The component library helped in this regard by allowing us to use similar components to our quoting and invoicing features, although we did take the chance to update the styles on some components as both quoting and invoicing had not been updated as a part of our UI Refresh.

This is the main Payment Claim builder. In a similar vein to our quote and invoice builder the user can edit items on the document to then send to their customer. The main challenge with the Payment Claims builder was that the user needed the ability to set either a specific dollar value or percentage of each item to be claimed. So the claiming function became one of the main interaction points of the feature. Users can enter either a specific dollar value or percentage into their respective columns on the builder, alternatively the user can select multiple items and ‘bulk claim’.
We tested the prototype with some users, including the ones we talked to earlier while researching the viability of the project. Results were very positive with a large amount of feedback to improve future iterations of the prototype.
The project is on-going and because of the size of the feature, the team has made the decision to split the feature into two different deliverables: The workflow of making a quote into a Payment Claim through to an invoice and the workflow for disputes, dispute resolution and anything else that touches our users’ customers.