The First Call Is Just Information Gathering

When a client calls because a process has broken, the first call has a specific job. We're not demoing anything. We're not pitching a solution. We're walking through the broken process step by step to fill in four fields: bucket, KPI, baseline, 60-day target.

If all four fill in by the end of the call, we can scope. If they don't, we schedule a follow-up for when they do.

The process usually describes itself

When someone calls because a spreadsheet broke or a workflow stopped scaling, they already know what's wrong. They can describe it in detail. That description is where the scoping information lives.

With Freedom Ag, Derek's first call centered on spray cards. Reps were spending 15 to 20 minutes per card: calling in job details from the field, someone at the office transcribing them, cross-referencing a label database manually. At five jobs a week that was manageable. At eight jobs in a day it created a backlog and compliance risk. He knew the number. He knew what fixed looked like: reps leaving the field with the card in hand.

With Homefront, the first call was about IFSP records and billing denials. Authorizations were tracked on a spreadsheet. Providers didn't have visibility into remaining units. Denials were arriving six weeks after the session, after the window to correct them had closed. The director knew the denial rate. She knew it had gotten worse as the agency's caseload grew past 150 clients.

Both calls had the same structure: describe the current process, describe where it breaks, describe what it would look like if it worked.

What we're listening for

Four things have to be present before we can scope anything.

First, a bucket: what category of problem is this. Documentation, authorization tracking, reporting, billing, scheduling. The bucket determines what we're actually building, an AI-assisted documentation tool or a records system with authorization logic or something else.

Second, a KPI: one number that proves the build worked. Time-to-spray-card. Denial rate. Time-to-session-note. Hours spent on report coordination per week. It has to be a number you can measure before and after. "Works better" isn't a KPI.

Third, a baseline: what that number is right now. This is the easiest field to fill. If the process is broken enough that someone called, they know the number. It's what's been taking too long or failing too often.

Fourth, a 60-day target: where the number should be 60 days after the first module ships. Not where it might be eventually. Where it should be in 60 days, based on what the first module will actually change.

What disqualifies a build

If the KPI is vague, we don't have the second field. "We want to be more efficient" doesn't give us a number. We ask what they'd measure to prove it's working. If they can't answer, the problem isn't scoped yet.

If the baseline is unknown, we don't have the third field. This happens when the broken process is still being tolerated rather than measured. "It takes a while" without a specific number means the pain isn't quantified. We ask them to track it for two weeks and come back.

If the 60-day target is unrealistic, the first module is scoped wrong. The target isn't what the whole portal will eventually deliver. It's what the first module, which addresses the highest-pain single task, will deliver in 60 days. If the first module can't move the number to target in that window, we scope a smaller first module, not a bigger promise.

What comes out of the call

When all four fields fill in, we have enough to write the first module brief. The brief names the bucket, the KPI, the baseline, the 60-day target, and the scope of the first module: exactly what it does, what it reads from or writes to, and what the operator does at each step.

When they don't all fill in, the call ends with a specific missing piece. Usually it's the baseline. We ask the client to track the number for two weeks and schedule a follow-up.

The call takes 45 minutes. If it ends with all four fields filled in, we scope the first module that week. If it ends with a gap, we wait. Building before the scoping is complete produces a module that solves a vague problem, which is the same as not solving it at all.