How Behavioral Framework Is Building an Operating Layer on Top of Its Systems

What happens when a provider structures its data for execution—not just reporting

David Iklodi joined Behavioral Framework in 2024 from investment banking. For the past two years, he’s been helping to improve operations at the company as VP of Operational Excellence.

That background matters—not because finance and ABA have obvious overlap, but because it gave him a different lens on how to read operational complexity as the organization scaled.

The data was already being captured—across practice management, CRM, scheduling, and clinical systems. The question was how to structure it so teams could move faster, make better decisions, and reduce the manual work between data and action.

That’s a common dynamic in ABA. What’s less common is deciding to build around it.

Instead of pushing individual systems further, Behavioral Framework made a deliberate choice to control an operational layer that connects them.

 “Lumary is our system of record and does what it does well, but we’ve also chosen to invest in our own proprietary technology that builds on top of it - pulling from Lumary and our other systems to shorten the distance between data and decisions,” David said.

The Problem That Surfaced First

Behavioral Framework operates a mixed delivery model that is majority home-based across the Mid-Atlantic.

That makes matching—connecting the right technician to the right client—one of the most operationally intensive things the business does.

At smaller scale, it’s manageable. Coordinators know who’s available, who’s a fit, who lives close enough. The judgment lives with the individual.

At scale, that breaks.

Brittany Doan is Vice President of Service Delivery and a BCBA by training—someone who spent years on the clinical side before transitioning into operations through staff training, retention, and placement. That path matters. It means she understands both what makes a match succeed clinically and what makes the process fall apart at volume.

Her team was responsible for matching across a growing caseload, a high-volume recruiting funnel and home-based work representing a meaningful portion of the business.

The data was there: insurance eligibility, drive time, schedule availability, language preferences, family constraints—all of it already captured inside Lumary.

The opportunity was to apply that information more consistently at scale, without the manual overhead that had started to slow the process down.

"As we scaled, matching consistently across a growing caseload needed a more structured approach than any individual could hold in their head," Brittany said.

So they built one.

Encoding How the Business Actually Works

The system they built—FrameworkOne—started with staffing.

But the more important story is how it was designed.

FrameworkOne pulls data from existing systems and structures it around how decisions are actually made on the ground. The logic is layered:

• Hard constraints — insurance, geography, baseline availability
• Weighted constraints — schedule fit, preferences, technician experience
• Flexible constraints — partial availability, trainable attributes

Those rules weren’t defined by a vendor.

They were defined by Brittany—drawing on clinical training and operational experience—and translated into a system by a developer working closely with the team.

BCBAs are trained not just in clinical care, but in how to define, measure, and adjust behavior over time. In an operational context, that translates into something specific: identifying what drives outcomes, testing constraints, and refining based on what the data actually shows.

The output is a ranked set of matches—“great,” “good,” or “poor”—with the reasoning visible.

A poor match isn’t discarded. It becomes a starting point.

“If a poor match is the best option, I want to see why,” Brittany said. “Can you work until 7:30? Can we train you on this? We’re able to make poor matches better.”

Before FrameworkOne, a coordinator would manually review profiles, calculate drive times in Google Maps, compare schedules across systems, and track decisions in spreadsheets.

Now, the matching logic runs in the background. Candidates surface immediately. Human judgment gets applied where it has the most impact.

“The trained human can do the most important part,” Brittany said. “FrameworkOne gets us to that part faster.”

The Pattern Behind the Tool

FrameworkOne didn’t stay a matching tool for long.

Because the underlying pattern—pull data, apply operational logic, surface decisions—extends well beyond staffing.

David had already been working a version of this problem on his own.

Reporting out of Lumary covered most needs. But some operational use cases required pulling across multiple objects and fields — work that typically involved manual steps and ended up scattered across spreadsheets.

 "There's a layer of reporting that sits between what's natively available and what would normally require a BI team or a six-month implementation,” David said. “By writing against Lumary's API directly, with privacy-safe tooling on top, we get there in days instead of quarters."

No data warehouse. No six-month implementation.

What made it possible was knowing the business well enough to know exactly what was needed—and being willing to find a path that didn’t require waiting for the platform to build it.

FrameworkOne builds on that same instinct, applied more broadly and more consistently.

What’s Being Built

FrameworkOne is evolving as a modular internal operating layer.

The matching system is live on Brittany’s team. A BCBA utilization dashboard—tracking cancellations and identifying where service hours are at risk—is rolling out to clinical leaders.

A text processing tool, built in close partnership with a developer, takes inbound cancellation messages and structures them automatically, so coordinators aren’t doing manual data entry across hundreds of interactions a day.

 "We prototyped it in days, validated it against live cancellation volume, and it's been the production process since,” David said. “The point isn’t the tool. It's how fast we can get from problem to working solution."

Each module is independent. All of them follow the same pattern: pull data already in the business, structure it around how the team operates, reduce friction around decisions that still need a human to make.

The system of record doesn’t change. Scheduling still lives in Lumary. Core workflows stay in existing systems.

What changes is the ability to act on the data—quickly, consistently, and in a form that fits how the work actually gets done.

“It’s modular right now,” David said.  “We’re focused on building automation and data-insights around our most impactful workflows in FrameworkOne.”

What’s Still Hard

FrameworkOne is working. That’s real.

It’s also early.

Matching gets more complex as the organization expands into new markets. Restaff data—why a placement didn’t work, what happened after—still needs to be more fully incorporated into the ranking logic. The goal is a system that learns from its own history and surfaces a true best match rather than just a ranked list.

“Being able to learn from itself is the next step,” Brittany said. “We’re right now in that phase—getting the restaff information into FrameworkOne so we can start writing rules and making it smarter.”

How far the layer eventually extends—and how much of it ultimately runs alongside Lumary versus how much supports decisions that were previously handled manually—is still an open question.

For now, the focus is clear: build where the operational friction is highest.

The Actual Takeaway

The most important part of this story isn’t the system.

It’s what made the system possible.

A team that understood the operational problem at a granular level. A leader who translated business logic into something a developer could build. A clinical perspective—Brittany’s—that brought both domain expertise and a disciplined approach to change.

Most providers already have the underlying data. They already understand the constraints, at least informally, in the heads of the people doing the work.

What’s less common is the decision to structure that understanding into something that scales—and to build the layer that supports it.

“If you have the context of what you need, and if you know the business really well, you can get to a solution much more quickly,” David said.

Behavioral Framework is still building.

But the operating layer is real—and it’s getting smarter.