Invoicing for Time Clock Labor
Taking millions of dollars in every-day job costing from manual to automatic.
Role: Product Designer (UX Research, UX & UI Design) • Date: October 2023 - Present
For more context on cost+ jobs and how we landed on this as an opportunity, click here.
The Problem
Cost+ builders struggle when calculating and invoicing time clock labor costs - keeping them from ultimately fulfilling their end-to-end invoicing process in Buildertrend.
The Results
In the first three months after launch, the time clock invoicing workflow has resulting in over $5 million costed and paid within Buildertrend without any manual effort.
The Solution
Introduce an simpler and faster workflow for importing time clock labor that mirrors the experience of other BT financial entities.
The final Time Clock labor import modal, featuring cost code identification, dates of labor, employee names, builder cost, markup %, and a final invoice calculation.
The efficacy of Buildertrend’s Invoicing tool hinges on the builder’s ability to pull line items directly from one place in BT (ex. bills, change orders, selections) → invoices.
When there is a gap in this pipeline, users are forced to either create invoice line items manually (based on their calculations) or look outside of Buildertrend to accomplish it (like in Quickbooks). This not only breeds an excess of unnecessary mistakes, but the error of including information twice can be deadly to a cost+ budget. Not to mention, a hell of a lot of extra time spent even getting there.
While we had already improved the ability and freedom of importing items to invoices, we were still missing one key part of builders costs: time clock labor. Their employees were clocking in 5 days a week, and those costs required an immense amount of manual effort to calculate and add/organize into an invoice.
Our goal in adding time clock invoicing was to reduce time spent in calculations and invoice creation, in addition to improving transparency behind the question of ‘what am I paying for?’ for our builders’ clients.
Want to look, not be told?
Check out this figma file to the right to see research, architecture, workflows, development & QA notes, scrapped iterations, and more.
Research & Discovery
The Cost+ initiative had 3 scrum teams working together, all of which were assigned a different area of the workflow; ours was “easier invoice creation.” When we noticed time clock invoicing was a gap, we initially were unsure of how broadly it would present itself as an issue. Namely, the concern from leadership was that it was too specific to help a wide span of customers.
Our first 2 weeks working on the project, our teams conducted about 50 user interviews in total, working through a vetted list of cost+ customers that was deemed the Builder Advisory Board. In combination with previous feedback on our public roadmap, CS conversations, and generally expressed usability concerns, I created a quick pattern identification of various feedback on time clock invoicing in order to see how we may approach our MVP.
When our team dove into the research, it was exceedingly clear that pursuing this opportunity was right decision. We confirmed this by taking the research to our customer support team and surveying what they believed were the most difficult problems to solve for the users they spoke to - where they said far and beyond time clock labor was vital.
Current vs. Desired State Journeys
The next task was to layout the general journey of a user creating an invoice (and sending it to their homeowner). The left is currently in our application, and on the right is a more desirable state that would simplify their workflow.
The current path to create an invoice.
How we’re aiming to simplify invoice creation.
The general UX goal, conversations with CS, and consolidation of past and current feedback made it really easy for us to define somewhere to start.
Click to see more details on this pattern identification.
Clear needs for our first MVP would include:
Pushing line items from the time clock page (create new, and add to existing)
Pulling time clock line items while inside an invoice
Builders need to be able to see what time clock labor has already been invoiced, so it won’t be duplicated
Cost codes are a must, descriptions are important, and line items must contain identifying information for the builder (employee name, date), but be careful about bringing them over so that the builder’s client can/can’t see them
Outlining Design Goals
Because the time clock import modal would be created from the same component as other Buildertrend workflows (like bills), I started by laying out all of the different modals that do this same action to form a comparison point of what we could potentially include and exclude.
From here I noted that many of the columns utilized in other entities do not transfer 1:1 over to the columns included in the invoice, sometimes because they didn’t exist and other times because they don’t logically need to be added to an invoice. Following this exploration, I wanted to get an idea of exactly how information was flowing from entities to the invoice, and how much we are translating to new columns or spaces in order to keep utilizing our current architecture.
The current billing invoicing translation. The different colors of notes represent different types of fields (static, dynamic, or a calculation).
Here, information like builder cost is brought over, but only within a calculation (builder cost x markup % = invoice amount), and when it hits the invoice it becomes a newly defined owner price.
More importantly, we noted that quantity always resets to 1, even though the builder cost that comes in on the invoicing modal is already a previous calculation created by multiplying quantity x unit cost. This was a huge issue we predicted that we decided to tackle later - a builder wants to know the final invoice line item quantity will represent the hours worked, and the unit price will be the hourly rate. Otherwise, it will conglomerate to one big cost, giving absolutely none of the cost transparency that would be required.
Below, we start to break down how the time clock fields can transfer and where calculations can be applied. Some concessions would be made temporarily, like the hourly rate and hours worked, and needing to address what titles should be created, but we would be able to transfer descriptions, the final owner price, and then later add the builder cost and markup columns to all invoices.
Our ideal time clock invoicing transfer for the MVP.
MVP and V1 Launch Feedback
Push / Add to Existing Owner Invoice was 1 of 3 main workflows designed for the MVP that can be found in the figma file.
V1 of the time clock importing modal.
V1 of the owner invoice after line items are imported.
Development Notes
During this process, our team worked with an additional agile crew from Artium that advised our scrum team to start vertical slicing our user stories, which was a massive help in getting an understanding of how we can define smaller user stories that still deliver value, and iterate as we go.
It would have been extremely easy here to define the blue sky version of the product and wait quarters to properly execute and release, but taking this route allowed us to get time clock invoicing to our users faster (about 2 months start to finish), and add on what was explicitly needed using their feedback. Minimizing the transfer of information, simplifying the user touch points in the process, and creating this ‘skeleton’ gave us a much-needed starting point to improve on.
What Was Missing? (User Feedback)
With the exception of smaller iterations we already had in the works (see ‘V2 Iterations’), the biggest needs we saw incoming from customers during interviews and CS calls were the quantity issue to be corrected, and shifts to be able to be organized by cost code within the invoice. We got to work on both while simultaneously planning our next releases. (See quotes below taken from customer feedback).
Problem Context: When users have multiple employees who work every day of the week, a builder is looking at importing 10-100 shifts from a 2 week period, usually splitting into multiple line items. This creates hundreds of line items that a builder now has to sort through every time they look at an invoice.
Problem Context: When a builder charges their client for labor, they want to know what work was done, for how many hours, and for how much per hour. This transparency gives clients insight into how their costs become calculated.
Exploring Different Designs
We explored a variety of different ways to accomplish similar tasks, one of which being filtering. If the user was able to utilize the import modal to filter out what they needed to select, that would make their invoicing process easier.
On the left of the photo, I noted all of the technical and design questions and concerns, the biggest of which is the code keeping track of what was selected, even when those same selected items were being filtered out.
Adding date and cost code filtering.
When we decided this was technical overkill, I moved on to testing out how we could simply group items with dropdown options. Only one group could be selected at one time, and then the user could select that group in one click to be brought over. This would lessen the amount of scrolling and selecting, and works particularly well for users who are billing and invoicing through cost codes.
We also explored consolidation - different from grouping in that consolidation would be a permanent affect to the line items. So instead of being able to group and ungroup (collapse and expand) line items, that consolidated group would be one line item reflecting the title, cost code, and total cost of the line items it was created from.
Simultaneous Work
We ended up not utilizing these directions in that immediate time frame mainly because another team working on the initiative had previously committed to grouping items by cost code on the invoice, but then decided they would explore that later down the road. Our concerns with consistency were that if the user could group or consolidate items on their import modal, but once imported, they were no longer in that state, it would be a misalignment of expectations and be extremely frustrating.
V2 Launch
Once we explored many of these different opportunities, we opted to add a couple key features as well as UX clean up in missing workflows.
Adding shift dates to headers for a better reference point of that shift’s overall work
Adding titles to the line items (‘Labor - Date’)
Date filtering (specific to the ‘pull’ workflow)
Improved button and action UX to complete the flow
Better alerts for users attempting to ‘select all’ when crucial items are missing
Here were our near-final designs for the header column, changing titles, and filtering by date.
An overview of our V2 time clock iterations.
The V2 release for the import modal.
The V2 release for the invoice modal.
Note on Simultaneous Work
While we completed this work, another team was adding builder cost and markup as columns on the invoice - helping us in the process of pulling more information over that can be shared with their clients (you can see these additions in the V2 designs).
Feedback and Usage
Time clock labor imported directly from this workflow currently accounts for $5 million in costs.
These workflows have been used over 2,000 times in the program, saving hundreds of hours of manual effort and work for the GCs utilizing it.
We are also continuing to track the events and their trends in MixPanel as we unravel more holistic ways for users to accomplish invoicing.
…Introducing Stacks! (Consolidation by Cost Code)
Returning to one of our biggest feedback points as soon as we had the sprint capacity was important, so we could finally tackle consolidating line items by cost codes. This is an in-progress project that I will soon write about this in a separate case study, as it is worth its own page in entirety!