The first call came on a Saturday afternoon. The voice on the other end belonged to the owner of a mid-sized electrical subcontractor, one of the largest in their region, and he got right to the point: his general contractor had frozen over $1.1 million in weekly payments accumulated over the past month, and he needed help. We flew out to his site on Monday.
Turns out the withheld payments were only the surface of the problem. The real threat was existential. The GC had started questioning whether the Sub could execute the project at all, and on a build of this magnitude, that kind of doubt leads to one outcome: removal from the job. For a subcontractor whose reputation, pipeline, and financial health were all riding on this single engagement, losing the project wouldn't just mean lost revenue. It would mean lost credibility in a market where your track record is everything.
We'll call this partner "the Sub," because we're still actively working with them and the situation with their general contractor remains delicate. What we can tell you is that this company was in the middle of the biggest operational leap of its history. They were scaling their electrical workforce from 100 to 300 electricians in two months while executing their first-ever colocation data center project, the kind of massive, mission-critical infrastructure buildout where the tolerances are razor-thin and one bad month can define you for years.
By the time we started working with them, they were five months into a nine-month project scope. And from the outside, things looked precarious.
The general contractor ("the GC") had started making serious claims. They alleged that the Sub was misstating the size of their workforce, ordering supplies haphazardly without proper documentation, and failing to complete the work they were contractually obligated to perform. On the other side of the table sat the end buyer, a major cloud company, watching the timeline slip and applying pressure of their own.
As a result, the GC had done what GCs do when trust breaks down: they turned off the money. Over $1.1 million in weekly payments withheld over the past month, pending proof that the Sub could demonstrate an accurate labor count, clean up their procurement process with documented delivery and inventory protocols, and show sufficient work completion with credible projections for the road ahead. And everyone involved understood that the payment freeze was a warning shot. If the Sub couldn't answer these questions convincingly, the next step would be termination of the subcontract.
"We weren't looking at a technology problem or even an operations problem. We were looking at a trust problem, and the only way to rebuild trust on a construction project is with data."
This is the kind of situation where most technology vendors would show up, demo some software, promise a dashboard, and leave. We knew from the start that wouldn't work here. What this team needed wasn't a product pitch. They needed someone who would sit in the trailer, understand the actual workflows (not the ones in the org chart, but the real ones), and build systems around what they found.
That's what SkillAxis does. And this engagement would put our entire methodology to the test.
What we actually found
Before we wrote a single line of code or configured a single workflow, we did what we always do: we went inside.
At SkillAxis, we start every engagement by baselining a company's core operations with executive leadership. The goal is straightforward but often uncomfortable. We need to understand where critical information is being lost and where the major bottlenecks are that slow a project down. Most companies have a general sense of their pain points. They know things are "messy" or that "communication could be better." What they rarely have is a precise diagnosis of where, exactly, the information chain breaks.
For this Sub, the diagnosis was stark.
Start with HR. The company's labor database, the fundamental record of who was employed, who was on-site, who was on vacation, and who had been terminated, was being updated once every four weeks. Four weeks. On a project where the GC was demanding daily proof of workforce size. The information wasn't stored in a system. It was stored in the HR officer's head. She knew who was working because she knew everyone personally. That works at 80 people. It doesn't work at 300.
Then there was production tracking. The Sub needed to track what work each foreman and their crew completed each day, because that's the basis for billing, for demonstrating progress, and for maintaining trust with the GC. The way this worked: foremen filled out paper sheets in the field. Those sheets made their way to the Project Engineer, who manually entered the data into a system. The PE was spending more than 20 hours per week on data entry alone, creating a backlog that was directly preventing the company from getting paid for work they'd already completed.
Meanwhile, the team had no high-level construction schedule of their own. They were reacting to whatever the GC asked for that day, a whack-a-mole approach that meant certain scopes of work were inevitably missed, further eroding the GC's confidence in their ability to execute.
And then there were the deliveries. On a data center project, material logistics are critical. You need specific components at specific times in specific quantities. The Sub had no current log of their inventory. When deliveries of critical material arrived on site, the material was either immediately consumed or, more often than anyone wanted to admit, lost. This triggered frequent re-orders, delayed work on other scopes, and created the appearance of the "haphazard ordering" the GC had complained about.
"This wasn't a bad company. This was a company that had outgrown its back-office infrastructure, and the project had outgrown their ability to manage it with the tools they had."
Here's what's important to understand, especially if you're running a sub yourself: none of these problems were unusual. In fact, they're endemic to the construction industry, particularly among subcontractors making the leap from mid-size residential or commercial work into large-scale industrial and mission-critical infrastructure. The informal systems that work at one scale (the knowledge in people's heads, the paper processes, the weekly updates) catastrophically fail at the next.
And this is where most technology vendors get it wrong. They see the symptoms, things like paper forms, manual entry, and spreadsheet chaos, and they prescribe software. Install this platform. Use this app. Subscribe to this dashboard. But they rarely take the time to understand the users on the ground, and the result is often additional work layered on top of already-strained back offices instead of genuine operational improvement.
Our approach is different, and it has to be. We focus on two core layers. First, creating tools that help you ingest data from core field operations, what we call data ingestion wedges that help translate the messy reality of field operations into structured, organized data. And second, structuring that information into databases that are both AI-readable and human-readable, so that the people doing the work can actually visualize and leverage this information for greater control across their business.
But none of that works unless you build it around the actual workflows, not the workflows you wish existed.
Rebuilding the labor foundation
We started with the labor problem because it was the most urgent. The GC wanted daily proof of workforce numbers, and the Sub couldn't provide it.
The first thing we did was consolidate the fragmented HR office into a single, dynamic labor database. Before our engagement, the company's personnel records existed across multiple spreadsheets, email threads, and above all, the institutional memory of one or two key people. When a new electrician was onboarded, the paperwork went into a folder. When someone was terminated, it was noted somewhere. When someone took vacation, the HR officer remembered. There was no single source of truth that the entire field team could reference.
We built one. The new system automated the core data flows that keep a labor database current: new personnel intake forms that feed directly into the database, a vacation registry that updates availability in real time, and termination records that immediately remove departed workers from active rosters. What used to be updated every four weeks was now updating daily, not because someone was doing more work, but because the work was being captured automatically as it happened.
The impact was immediate. For the first time, the entire field leadership team had confidence in who was supposed to be working on any given day. Foremen could see their crews. The project manager could see total headcount. And the data existed in a form that could be reported to the GC.
The dynamic labor database gives field leadership a real-time view of their active workforce, a capability the team previously lacked entirely.
But knowing who's employed isn't the same as knowing who's actually on site. So we implemented a workforce tracking system, initially through our own internal QR-based check-in system that integrated with the labor database, giving the team real-time visibility into hours of work completed by each crew. When workers checked in, the system logged it. When they checked out, it was recorded. No more guessing, no more manual timesheets floating through the trailer.
This data became even more powerful when we integrated it with Connecteam, the GC's workforce management app. By pulling Connecteam data into our system, we could cross-reference the Sub's internal records with the GC's own attendance data. This resolved the labor visibility concern that had been at the heart of the payment dispute. The numbers matched, the data was verifiable, and the GC could see it for themselves.
Perhaps most importantly, we gave the HR team the ability to query this database in natural language. Need to know how many hours a specific crew worked last week? Ask. Need an individual labor report for an electrician across the past month? Ask. Need total headcount by trade and shift? Ask. The kind of reporting that used to take the better part of a week, assembling data from multiple sources, cross-referencing spreadsheets, formatting reports, could now be done in minutes. And it wasn't just faster. It was more accurate, because the data was coming from a single, continuously updated source.
From paper sheets to billable work tickets
With the labor foundation in place, we turned to production tracking, the system that would determine whether the Sub could demonstrate the work they'd actually completed.
The existing process was simple to describe and painful to execute. Every day, foremen in the field would fill out paper daily reports: handwritten logs of what their crew accomplished, which areas they worked in, and what materials they used. These paper sheets would make their way back to the trailer, where the Project Engineer would sit down and manually transcribe each one into the company's tracking system. Twenty-plus hours a week, every week, just entering data.
The backlog this created wasn't just an operational nuisance. It was a cash flow problem. The company couldn't bill for work that hadn't been entered into the system, and the PE was perpetually behind. Completed work sat in limbo, done in the field but invisible in the books.
We built a foreman-facing app that addressed this from both directions. Foremen who were comfortable going digital could enter their daily reports directly into the app. But we knew, because we'd spent time in the trailer and on the floor, that not every foreman was going to make that switch overnight. Some of these guys have been doing paper sheets for 20 years. So we built a second path: foremen could photograph their handwritten paper sheets, and AI would extract the relevant information (crew members, areas worked, tasks completed, materials consumed) and convert it into structured, billable work tickets.
The foreman app supports both digital entry and photo capture of handwritten sheets, meeting field teams where they actually are.
This is a good example of what we mean by "data ingestion wedges." The messy, analog reality of a construction jobsite (paper sheets, verbal updates, photos on someone's phone) needs a bridge into structured digital data. You can't just tell a foreman to use an iPad and expect adoption. You have to design the ingestion point around the actual behavior of the highest-leverage people on the project.
The production tracking system solved the PE's bottleneck, but it also enabled something the team had never had: a high-level view of project progress. Before we arrived, the Sub had no consolidated schedule of their own. They were responding to the GC's daily requests, essentially playing defense every single day. Certain scopes were missed because the team was overwhelmed with the volume of incoming asks, and there was no system for prioritizing what mattered most.
Our app integrated directly with Procore, the project management platform the GC was already using, and pulled action items assigned to the Sub into a single view. The Project Manager could then assign specific foremen to specific items, ensuring that scopes of work were being prioritized intelligently rather than reactively. Critical milestones that had been slipping were now visible, assigned, and tracked.
The shift from reactive to proactive is hard to overstate. When a subcontractor can walk into a coordination meeting with the GC and say, "Here's what we completed this week, here's what's assigned for next week, and here's the data to back it up," the entire dynamic of the relationship changes.
Finding the lost inventory
The delivery tracking problem was, in some ways, the most operationally damaging of the three. It's also the most common in construction.
Here's how it typically works on a project of this scale: material gets ordered weeks or months in advance. When it arrives on site, it needs to be logged, stored in a known location, and allocated to the scope of work that requires it. In theory, this is straightforward. In practice, especially on a data center project with hundreds of different components, multiple staging areas, and a workforce that's doubled in size, it's chaos.
The Sub had no current inventory log. When deliveries arrived, the material was either immediately consumed by whatever crew needed it most urgently, or it was set down somewhere on a sprawling jobsite and effectively lost. The consequences rippled in every direction: work was blocked because material that had already been delivered couldn't be found. Re-orders consumed budget and delayed timelines. And the GC's claim that the Sub was "haphazardly ordering supplies" was, from their vantage point, supported by the evidence. They could see material arriving but couldn't see it being tracked or allocated.
We built an end-to-end inventory management system that followed the material from request to allocation. Foremen could submit material requests through the app, specifying what they needed, for which scope of work, and by when. An inventory manager would log incoming deliveries, tally current stock, and reconcile what was on hand against what had been requested. Inventory was then formally allocated to specific scopes of work, creating a paper trail that answered the question the GC kept asking: where is the material, and what's it being used for?
The inventory management system tracks material from request through delivery to scope-based allocation (data redacted for privacy), eliminating the lost-material problem that was blocking critical milestones.
This wasn't glamorous work. There was no machine learning model performing miracles here. Just clear process design, a system that matched the actual workflow of how material moves on a jobsite, and an interface simple enough that an inventory manager could use it without training. Sometimes the most impactful technology isn't the most sophisticated. It's the one that removes a specific bottleneck that everyone knows exists but no one has systematically addressed.
What one month looks like
We want to be honest about where things stand, because this engagement is still active and the work is still unfolding.
After one month of deployment, the core systems are in place and operational. The labor database is live and updating daily. The foreman app is being used by crews in the field. The inventory management system is tracking material. These are real tools being used by real people on an active jobsite, not prototypes sitting in a staging environment.
But adoption is a process, not an event. Some foremen took to the app immediately. Others are still using paper sheets and photographing them. Some crew leads are checking in via QR every morning without prompting. Others need reminders. This is the reality of deploying technology on a construction site. The people using these tools didn't ask for them, and their primary job is to install electrical systems in a data center, not to learn new software.
Any construction owner who's tried to roll out a new system knows this tension. It's why our engagement model doesn't end at deployment. We maintain our presence and our relationship with the team members who are driving adoption. When someone leaves, we help recruit and onboard their replacement. When a workflow isn't working the way we designed it, we adjust. When the GC changes their reporting requirements, which happens regularly on a project this large, we update the tools to match.
What's already changing is the dynamic between the Sub and the GC. Where there were accusations of misstated workforce numbers, there's now a database the GC can verify. Where there were claims of haphazard ordering, there's now an inventory trail. Where there were doubts about work completion, there's now daily production data tied to the GC's own Procore action items.
The threat of removal from the project, the existential risk that brought us in, has receded. The conversation has shifted from "prove you're doing the work" to "let's look at the data together." And in construction, that shift is everything.
Why most digital transformations in construction fail
We'd be lying if we said this was a unique story. The details are specific (the data center, the frozen payments, the rapid scale-up from 100 to 300) but the underlying pattern is one we've seen over and over again.
A construction company grows. They win a project that's bigger or more complex than anything they've done before. The informal systems that got them here, the knowledge in key people's heads, the paper processes, the weekly update cadence, can't keep up with the new demands. Information starts falling through the cracks. The back office gets overwhelmed. And by the time leadership realizes how deep the problem runs, they're already in crisis mode.
The construction industry's response to this pattern has historically been to buy software. There's no shortage of options: project management platforms, workforce tracking apps, inventory systems, scheduling tools. Billions of dollars flow into construction technology every year. And yet the industry's productivity growth remains stubbornly flat.
The reason, from where we sit, is straightforward. Software vendors build products for an idealized version of how construction companies operate, not the messy reality of how they actually work. They design interfaces for office workers, not foremen with calloused hands and dusty phones. They assume clean data inputs when the actual inputs are handwritten paper sheets and verbal updates over radio. And they almost never invest in the implementation and adoption work that determines whether the tool gets used or becomes shelfware.
At SkillAxis, we've organized our entire approach around this failure mode. Our methodology has two layers. The first are the data ingestion wedges: purpose-built interfaces and automations that meet field teams where they actually are and translate their existing workflows into structured data. A QR check-in that takes three seconds. A photo capture that turns a paper sheet into a database record. A material request form that a foreman can fill out on their phone.
The second layer is structuring that data into AI and human-readable databases, systems where the information can be queried in natural language, visualized in real-time dashboards, and leveraged across the business for everything from daily reporting to invoicing to strategic planning. The goal isn't just to digitize existing processes. It's to give construction companies a fundamentally new level of visibility and control over their operations.
But the technology is only half the story. The other half, and honestly the harder half, is our consultative approach to implementation. We don't throw tools over the wall and hope they land. We baseline operations with leadership. We build workflows collaboratively with the team. We identify competency gaps and, when necessary, pull from our network of seasoned construction professionals to staff the expertise that's missing. For larger enterprises, we deploy our teams directly to site, working alongside field leadership to see what executives sometimes miss once they hit a certain scale.
And after deployment, we stay. We maintain the tools. We work with the people using them. We adapt when things change, because on a construction project, things always change.
"Construction companies don't need more software. They need someone who will sit in the trailer with them and figure out what's actually broken."
That's the bet we've made with SkillAxis. And with this engagement, messy and unfinished and still very much in progress, we're seeing what happens when you take that bet seriously. The Sub isn't out of the woods yet. The data center still needs to be finished. The GC still needs to be satisfied. The payments still need to flow.
But for the first time, this team has the data to back up their work, the systems to track their progress, and the visibility to manage their project proactively instead of reactively. They walked into this engagement facing the real possibility of losing the largest project in their company's history. One month later, they're still on it, and they're building the operational foundation that will carry them into the next one.
It's a start.
This case study reflects SkillAxis's ongoing engagement with a design partner. We plan to update this piece as the project progresses and outcomes are finalized. If you're a contractor or subcontractor facing similar operational challenges, especially on large-scale industrial or mission-critical infrastructure projects, we'd like to hear from you.