Catching Survey Problems Weeks Earlier: What a Six-Week Feasibility Sprint Proved

Client Overview

An ATM installation company responsible for site surveys and installation for banks. Every installation starts with a site survey: clearances, measurements, and photos of the location. One senior specialist reviews each survey and decides what the job needs, from the ATM unit to electrical, low-voltage, and surround work. That review is where the company's growth runs into a wall, because only one person can do it.

Surveys arrive in waves tied to bank rollouts, often hundreds per rollout, with field crews completing five or six a day. The review itself takes 20 to 30 minutes, but each survey waits in line behind all the others, so going from survey to recommendation takes weeks. The expensive part comes when the review finally surfaces a problem. A missing or incorrect measurement means sending a crew back to the site, sometimes a month after the survey, which costs money and pushes the installation back even further.

Challenge

The client wanted to know whether AI could turn a completed site survey into the same recommendation their specialist makes today, reliably enough to lean on as volume grows.

We already knew something could be built. The question worth paying to answer was how accurate it could get, and how expensive that accuracy would be to reach. The inputs made that a real question:

• Site surveys were handwritten, then photographed or scanned to PDF.
• Calculations lived in Excel, and a lot of job context lived in emails and phone calls.
• Manufacturer cut sheets were written for installation crews, not software. Clearance requirements for ADA compliance and technician access are given in feet and inches across many ATM models and minor versions, often before anyone knows which model is going in.

The client also had less digital history than they expected. An AI recommendation engine is only as good as the past data it learns from, and nobody knew yet whether that data could support one.

Solution

We ran a fixed-fee Technical Feasibility Sprint over six weeks. Instead of writing a build proposal on assumptions, we built a real, minimal version of the recommendation engine on the client's own historical jobs and measured what it could do.

First, we sat down with the specialist and defined an answer key: the discrete decisions every recommendation comes down to, and which mistakes are serious versus cosmetic. Then we assembled roughly 100 past through-wall ATM replacement jobs where both the survey and the specialist's recommendation existed, and tested the engine against calls it had never seen. We also ran the same surveys repeatedly with the reference data organized a little better each time, to see whether cleaner data would buy meaningfully better accuracy.

What We Found

The original plan didn't hold up. Indexing the manufacturer cut sheets so the engine could pull the right clearances for each job produced results that were consistently wrong in ways you can't build on. The measurements were written for a technician with years of ATM knowledge, and they didn't convert cleanly into something a system could calculate against. A recommendation tool has to be consistently right, so that approach was off the table as a first version.

The part we expected to fail worked. We fed the model site survey photos (a tape measure against a concrete pad, the grade of a walkway, mounting heights) expecting little. It returned useful callouts almost on the first try, and in one case recognized on its own that a photo related to ADA compliance, which we hadn't told it. Converting handwritten survey pages into structured data was also more accurate than we expected going in.

The biggest constraint turned out to be process, not the model. The historical data didn't exist in the shape a fully automated engine needs, and the specialist was spending much of the review hunting through Dropbox folders, email threads, and spreadsheets to assemble the job.

Outcome

The specialist's review is the narrowest point in the client's funnel. Every survey has to pass through one person before an installation can be scheduled, so the company can only take on as many jobs as that review can clear. The sprint's real result is a plan to open that bottleneck up and create capacity the business doesn't have today.

The sprint changed what version one should be. Instead of an engine that replaces the specialist's judgment, the right first step is a review workstation: every survey photo and extracted measurement on one screen, the measurements the system can read reliably already answered, and anything uncertain flagged for the specialist to check. The payoff is speed, and it doesn't depend on perfect accuracy on day one.

Instead of assembling each job from Dropbox folders, email threads, and spreadsheets, the specialist spends their time on the calls only they can make. The same person clears more surveys, the queue behind each bank rollout gets shorter, and the company can take on more work before it needs a second specialist.

The longer-term path is structured digital survey intake on a phone or tablet, so measurements are captured correctly at the site. That builds the clean history needed to measure accuracy over time and automate more of the recommendation as it improves.

The biggest savings come from catching problems earlier. Today a missing or incorrect measurement can sit in the queue for a month before the review catches it, and then a crew has to go back out. Flagging those gaps as soon as a survey comes in, or capturing the data correctly at the site in the first place, means go-backs happen right away instead of a month later.

The client left with a working prototype, a clear picture of what production would take and cost, and a plan that is now part of their technology roadmap. After the readout, their team told us: "Your team did a great job with the project and presentation today."

Why This Matters

A feasibility sprint is supposed to replace a guess with evidence before real budget is committed. Here it did more than confirm the idea. It showed the original approach wouldn't be reliable on this data, found a faster path to value in a part of the problem nobody expected to work, and pointed the client at the process change that makes everything after it possible. Finding that out in six weeks for $15K is far cheaper than finding it six months into a build.

This kind of sprint also costs less than it used to. We build with an AI-assisted development workflow, which is what lets us put a working prototype on real client data inside a six-week, $15K engagement.

Learn more about the Technical Feasibility Sprint