Field Notes From The Work. 

The situation

The company was growing quickly, which is how the problem started. Claim volume rose faster than the team handling it, and the work that used to be absorbed by whoever had capacity stopped being absorbed at all. Claims were submitted, and then nothing happened to them.

The backlog itself was not the interesting part. The interesting part was that nobody could say how large it was. Different people had different counts, pulled from different views, on different days — so leadership was managing a number it could not verify and a problem it could not size.

Why it persisted

Everyone involved was competent and busy, which is exactly the condition in which this failure mode survives. Follow-up was the kind of work that is always important and never urgent, so it lost every scheduling conflict it entered.

• ▲No single owner. Follow-up belonged to the team, which meant it belonged to nobody in particular.
• ▲No cadence. Work was picked up when someone had a gap, not on a schedule anyone could rely on.
• ▲No visibility. Without a weekly AR report, the backlog only surfaced when cash flow tightened — weeks after the cause.
• ▲No escalation rule. A claim that stalled twice looked identical to one that had just been submitted.

What we placed, and why that role

The company's instinct was to add billing capacity — more hands on more claims. We scoped it differently. Volume was not the constraint; ownership was. Adding throughput to an unmanaged process produces a larger unmanaged process.

So we placed a Revenue Cycle Manager: eleven years across US provider groups, fluent in payer behavior, and used to inheriting a mess. Senior enough to redesign the workflow rather than work inside the one that had failed.

The first ninety days

The sequence mattered more than any individual change. Ownership was assigned per stage of the cycle first, so that every claim had a named person at every point. Then a daily follow-up workflow replaced ad-hoc catch-up, with explicit rules for when a stalled claim escalated and to whom.

Weekly reporting came last, once the underlying data was trustworthy enough to report. That order is deliberate — a dashboard built on an unmanaged process just publishes the confusion more widely.

What changed

Within three months the key bottlenecks were removed and claims were progressing predictably rather than episodically. Revenue improved, and — the more durable outcome — leadership could finally see the cycle in something close to real time.

The relationship grew from there. What began as one role is now almost ten embedded Pathfinders across the business. That growth pattern is the one we trust most: it starts with a specific operational problem, not a platform conversation.

One scoped role, placed through the standard S360 process, then expanded on the client's initiative as the first placement proved out.

The situation

The provider had a real list, real referral relationships, and a real reason to stay in front of both. What it did not have was a system. Campaigns went out when someone remembered, to everyone, from a template that had been edited so many times nobody could say what it originally said.

Open rates sat between 15 and 22 percent. That range is not catastrophic, which is part of why it persisted — it looked like an average result rather than a broken one.

Why optimizing wouldn't have worked

The obvious move is to test subject lines. We did not start there, because the constraint was underneath the copy.

• ▲Deliverability was degraded by years of sending to unengaged and invalid addresses.
• ▲One list, no segments — so every message was slightly wrong for almost everyone who received it.
• ▲No triggered sends, which meant the most relevant moments (an intake, a referral, a lapse) generated nothing at all.
• ▲No reporting anyone trusted, so there was no basis on which to decide what to change.

The rebuild, in order

Hygiene first: suppress and re-permission, repair authentication, and get sending reputation back to a state where inbox placement was not the hidden variable in every result.

Then segmentation — referral partners, active clients, lapsed contacts, and prospects treated as genuinely different audiences rather than one list with different names on it.

Then automation: eighteen workflows covering intake, nurture, referral follow-up, and re-engagement. The point of the automation was not volume. It was that the right message now fires at the moment it is relevant, without depending on anyone's memory.

The result

Open rates moved from the 15–22% band to 62.3% — roughly triple the prior baseline — on a system that now runs continuously rather than in bursts.

The number people quote is the open rate. The change that actually matters is that the channel became infrastructure: it works when nobody is thinking about it, which is the only state in which a small team's marketing survives a busy quarter.

A single Marketing Pathfinder, scoped to own the channel end to end rather than execute campaigns on request.

The situation

Decisions were being made off spreadsheet exports. Each export was accurate at the moment it was pulled and stale by the moment it was read, and because every department pulled its own, no two conversations started from the same numbers.

This is the ordinary version of the problem — not a dramatic failure, just a permanent tax on every decision the leadership team made.

What the engagement produced

We mapped how work actually moved, consolidated the reporting into one operating view, and defined the cadence and ownership model to run the business against it. Nothing was migrated; the underlying systems stayed exactly where they were.

• ▲A current-state map of workflows, systems, and data across the business.
• ▲One operating view, with a single definition and a single "as of" per number.
• ▲A meeting and review cadence tied to that view rather than to ad-hoc exports.
• ▲An explicit ownership and escalation model, written down.

The part most engagements get wrong

A deployment like this succeeds on the day it goes live and fails over the following year, quietly, if nobody owns it. Systems drift. Integrations break. New processes appear and don't get reflected. The operating view degrades back into a set of exports, and the organization concludes that consulting doesn't stick.

The client saw this coming and acted on it. Rather than treating the roadmap as a finished deliverable, they treated it as something that now required an owner with authority over the technology stack.

Why the outcome was a hire

They hired a CTO Pathfinder through S360 Staffing to run the stack and maintain the system. Consulting set the direction; staffing kept it alive.

This is also the cleanest illustration of why we split the two service areas but keep them adjacent. A roadmap tells you which bottlenecks are process and which are capacity. When the answer is capacity — as it was here — the next step is a person, and the handoff between the two shouldn't require starting over with a new vendor.

A consulting deployment first, then a placement scoped directly from what the deployment revealed.

The operation

The client supports physician groups and pharmacy partners through Remote Patient Monitoring and Remote Therapeutic Monitoring programs. Patients are enrolled, monitored, and consulted; the services bill under a defined set of CPT codes — 98980, 98981, 99457, 99458 — across multiple physician entities and professional corporations.

That structure is the whole story. Revenue did not arrive through one pipe. It arrived through several entities, several data sources, and several partners who each needed a statement that agreed with the others. Billing was not a transaction here; it was a reconciliation problem wearing a billing costume.

What it looked like before

The process worked, in the sense that payments went out. It worked by consuming senior internal attention every single cycle. Billing data lived in the billing platform; commercial context lived in HubSpot; spend and payables lived in Ramp and QuickBooks Online; and the connective tissue between all of it lived in maintained spreadsheets.

Each cycle meant pulling the data, identifying completed consultations and eligible monitoring services, preparing payment summaries for pharmacy partners and physician groups, then reconciling the summary back against the underlying records. When the two disagreed — which they did — someone senior stopped what they were doing and went looking.

• ▲Billing data consolidated by hand from four systems and a set of spreadsheets.
• ▲Eligibility for monitoring services confirmed manually, service by service.
• ▲Payment summaries reconciled against detail with no structured trail back to source.
• ▲Discrepancies investigated ad hoc, by whoever had context that week.
• ▲Incomplete supporting information chased across physician groups and pharmacy partners.

Why it mattered more than it looked

Nobody was losing sleep over the billing process, which is precisely why it was expensive. The cost was not a visible write-off; it was senior time, spent every cycle, on work that produced no new value once it was right.

The risk was real too. A discrepancy that went unnoticed became an inaccurate statement to a partner, and finalization slipped while research happened. The operation had grown past the point where a careful person with a spreadsheet was an adequate control.

The baseline we could measure

Consultation volume was one of the few things the data could state cleanly, and it showed the direction of travel: 331 consultations in April, 402 in May, 497 in June, 503 in July, 440 in August. Roughly a third more activity in high season than at the start, on the same manual process.

That is the shape of problem worth fixing with a person rather than a patch. Volume was rising, the process was not scaling, and the constraint was structural rather than temporary.

What the Pathfinders took on

We scoped this as controller-level finance work, not billing clerical work. The role had to be senior enough to redesign the validation chain and stay accountable for the numbers at month-end.

• ▲Reviewing and validating billing data across entities and sources.
• ▲Reconciling billing detail against the supporting reports.
• ▲Identifying discrepancies and researching their actual cause.
• ▲Preparing and reviewing partner payment summaries.
• ▲Supporting pharmacy and physician billing processes end to end.
• ▲Chasing missing supporting information from internal stakeholders.
• ▲Carrying billing into month-end close and financial reporting.

The change that made the difference

The core shift was refusing to reconcile summary to summary. Summarized reports agree with each other for many reasons, only one of which is being correct. The Pathfinders worked from the raw billing data forward and traced every variance back to its origin.

That produced the distinction the client had been missing: a difference between raw data and a payment summary is either a genuine error or a legitimate exclusion — and until you can tell which, every variance costs the same investigation. The workflow now runs in a fixed order: raw billing data, validation, reconciliation, discrepancy investigation, payment summary, final review.

Because the engagement spanned several entities, systems, and partners, the workflow was refined progressively rather than installed in one pass. The Pathfinders were contributing to live reconciliation during onboarding and tightened the process as they learned the client's billing structure.

What changed

The strongest claim we will make is the one we can support: billing accuracy and data validation improved materially, and variances are now explained rather than absorbed. Reconciliation moved from an act of diligence to a control with a repeatable path.

The second outcome is capacity. Recurring review, reconciliation, discrepancy research, and payment-summary preparation left the internal team's plate. That time went back to healthcare operations and partner relationships — which is where a healthcare services company should be spending senior attention.

We are deliberately not quoting a recovered-revenue figure. The return here came from accuracy, stronger controls, visibility into billing activity, and reclaimed capacity. Inventing a dollar number for that would make the case study better and the reporting worse.

Controller-level finance Pathfinders embedded in the client's billing and accounting workflow, accountable through month-end close rather than task-by-task.

The number everyone is citing right now

MIT's 2025 State of AI in Business report — often called the GenAI Divide study — reviewed roughly 300 public AI deployments alongside dozens of executive interviews and found that about 95 percent of enterprise generative AI pilots showed no measurable return.

The headline number got the attention. The more useful finding got buried underneath it: the study didn't blame the models. It pointed at integration — at pilots that never made it past a demo because nobody redesigned the process the model was supposed to sit inside. The same research found that back-office functions, not the sales and marketing pilots most companies fund first, delivered the strongest returns when AI was actually integrated into how the work got done.

What “operational” actually means when a pilot stalls

Ask most teams why their AI pilot never scaled and you'll hear some version of “the model wasn't good enough” or “the data was messy.” Dig one layer deeper and the same pattern shows up almost every time.

• ▲The output has no owner. Someone builds the tool, but nobody's job actually changes to use it.
• ▲There's no rule for when a human steps in. The model runs, and it's unclear whose job it is to catch what it gets wrong.
• ▲The tool sits next to the existing process instead of replacing a step in it. People end up doing the work twice.
• ▲Success gets measured by activity — how many times the tool was used — instead of whether the outcome actually improved.

The fix isn't a better model, it's a rebuilt process

None of that gets solved by switching vendors or expanding a prompt library. It gets solved by treating the rollout as a process change first and a technology change second: naming who owns the workflow, setting the rule for when a human overrides the model, and measuring the thing that was actually supposed to improve.

This is the problem the Pathfinder model was built to solve, and it maps directly onto the four failure patterns. Take a client handing off HR Operations. Under a typical pilot, someone installs a tool and hopes the team adopts it. Under a Summit360 engagement, a Pathfinder owns HR Operations end to end — so each failure point is closed before it can open.

The nine spreadsheets problem

Most growing companies don't lack data. They lack a shared version of it. Recruiting keeps its own tracker. Finance keeps its own. Client delivery keeps its own — usually a spreadsheet someone updates by hand every Friday because that's when the numbers are due somewhere.

Each one is technically correct, and none of them agree, because each is a snapshot taken at a different moment by a different person with a different definition of “active” or “closed.”

Why more dashboards usually make it worse

The common fix is to buy a dashboard. Then another one, because the first didn't cover finance. Then a third, because the second didn't cover client delivery. A year later there are four dashboards pulling from different systems, none of which reconcile with each other or with the spreadsheets still running underneath them — and the standing meeting exists specifically to argue about whose number is right before anyone can talk about what to do about it.

What “operating system” actually means here

A management operating system is a single layer that pulls from the systems already in place — a CRM, a case management tool, a finance platform — and turns them into one live view everyone works from. Not a copy of the data sitting in a slide deck by the time anyone sees it. A real-time read on it.

Picture a single screen showing case status distribution, average time to resolution, and caseload by manager, sourced directly from the systems of record instead of retyped into a spreadsheet the night before a meeting. That's the difference between reporting on the business and actually running it from one place.

The meeting that stops needing to exist

Once everyone is looking at the same numbers, pulled from the same source, in real time, the standing meeting changes shape. It stops being a reconciliation exercise and starts being a short conversation about the one or two things that actually need a decision. Most weeks that's fifteen minutes instead of an hour — because the first forty-five were never really about decisions. They were about agreeing on what the numbers even were.

Every Basecamp engagement includes this reporting layer as standard, pulling from whatever systems a client already runs so the operating system reflects reality rather than replacing it with something new to maintain. A client that used to spend Friday afternoons reconciling four spreadsheets instead logs into one live view of caseload, intake, and resolution time.

Fluency stopped being the differentiator

A few years ago, knowing how to use AI tools well was a genuine selling point on a resume. That window closed. Clients don't notice when a team member is AI-fluent anymore — they notice when one isn't, and by then it's already cost them time. Fluency didn't disappear as a requirement. It just stopped being something anyone gets credit for having. It became the floor, not the ceiling.

What the AI Academy actually covers

The S360 AI Academy isn't a welcome packet or a half-day orientation. It's a real certification covering the specific AI tools, workflows, and standards each Pathfinder will use on the job, tested before anyone is cleared to work on a client account. Less than 4 percent of applicants make it through the full process, and every single one who does is 100 percent AI Academy certified before placement. No exceptions, no partial credit.

Why this happens before placement, not after

Training a new hire after they've already started means the client absorbs the learning curve — one slow week, one missed detail, one “let me figure this out” at a time. Training before placement means the ramp-up happens on Summit360's clock, not the client's. By the time a Pathfinder sees their first ticket, report, or lead, the tools aren't new to them. The workflow is.

What this looks like day to day

A Pathfinder placed in Sales Support already knows the AI-assisted workflow for CRM hygiene and lead research before they see a single record. One placed in Accounting & Finance already knows which parts of reconciliation the AI tools handle and which parts still need a human check, before they open the books. The certification isn't a credential sitting in a file. It's the reason day one looks like week four.

None of this is visible the way a dashboard is, but it shows up where every process improvement eventually has to show up.