ABA software vendors told buyers where to press before signing: failure states, implementation teams, contract length, and the workarounds that expose bad design.
Key Takeaways
- Broad implementation questions get sales answers: Asking how long implementation takes produces a rehearsed number. Asking where companies typically struggle implementing the software forces the vendor to describe its own failure modes.
- The demo is a curated environment: Panelists described demos as sales conversations with perfect data and clean workflows. Trialing the product or meeting the implementation team before signing checks that.
- Workarounds are evidence, questions are noise: Users asking where to find things are climbing a learning curve. Multiple users hitting the same wall, or teams building spreadsheets alongside the system, indicates a design failure.
- One person holding it together is a failed rollout: When a single employee keeps an implementation alive by fixing everyone else’s work, that reads as dedication and functions as a human patch. The panel treats it as the clearest sign adoption never happened.
The premise came from the moderator, before any vendor said a word. Lexi Rand, Vice President of Growth and Strategic Initiatives at Autism First and a Board Certified Behavior Analyst, laid out the pattern she wanted the panel to address: bad technology does not fail quietly. It adds documentation on top of documentation, pulls supervisors away from judgment work, disrupts the workflows clinicians have built their day around, and eventually people leave. “And we call it a staffing problem,” she said, “when the real cost is a decision made in a room where the clinicians never were.”
What followed, in a Boston ballroom at ABA CARES this month, was an hour of five people who sell software to ABA organizations explaining, with more candor than the format usually produces, how to make their own sales process harder to survive.
Why an ABA Software Demo Is a Sales Conversation With Perfect Data
Charlene Kurth, Chief Operating Officer at Office Puzzle, started with the misconception underneath most failed rollouts. “People often consider technology to be plug and play or magic,” she said. “That they see something during a demo, which remember is a sales conversation with perfectly curated data, with a platform that’s meant to work exactly the way it is, and that’s not always the case when you get into the actual workflow.”
Jeffrey Morelli, Chief Executive Officer and co-founder of Silna, put the market context around it bluntly. “The landscape is riddled with folks who overpromise and underdeliver, have really shiny demos, have really beautiful websites,” he said, “and the reality is you can just do it better internally with your staff.”
Kurth’s second point is one operators rarely think of as a message to staff. “When you make a decision to implement software, especially if it’s something with a long-term contract, you’re essentially telling your team, I’ve made this decision for you; it better work,” she said. Bring the people who will use the product daily into the evaluation: an owner weighs cost and features, and somebody else lives inside the clicking.
The warning has recent precedent. Operators who standardized on one automation vendor were given a 90-day clock when Thoughtful AI wound down, and analytics tools routinely underperform in this sector because the underlying data is dirty and the problem was never defined. Neither failure shows up in a demo.
The ABA Software Questions That Do Not Get Sales Answers
Kurth’s first question is a reframe of the one everybody asks. Ask how long implementation takes and the answer is rehearsed. “The critical question is where do companies typically struggle in implementing your software,” she said, so the vendor has to name what is hard about its own product. Her second is procedural: “Can I meet someone on your implementations team or try your product before I sign a contract?”
Morelli’s version is about failure states. “I want to understand who is the solution not good for,” he said. “When has this not worked out in the past? Give me the social proof.” A vendor who cannot name a poor-fit customer is either new or not answering.
Joe Burst, Director of ABA at Vivantium, added the resourcing question buyers skip because it is about themselves rather than the vendor: how much of your own team’s time will this take, and when. “You need to allocate resources to an implementation,” he said, which means the signing date and the implementation date are two different decisions.
The most striking answer came from the person whose job is getting signatures. Stephen Donaldson, Chief Revenue Officer at Boost, advised buyers against long-term contracts up front. “Maybe that is unpopular to say as someone who asks people to sign contracts,” he said. “But if my software, my product can’t prove itself, then I shouldn’t force you to stick around just because I needed a three-year agreement from you.” A vendor unwilling to negotiate that, he said, is telling you something.
Acuity has also profiled the product leaders building the tools ABA providers depend on, a useful cross-check when a salesperson is the only person a buyer meets.
After You Sign: Telling a Software Design Failure From a Learning Curve
The second half of the hour was about the signals that appear once the contract is live. Shridhevi Veerappan, Clinical Solutions Manager at RMS ABA and a Board Certified Behavior Analyst, drew the line first. “If you have multiple users having the same problem, if there are workarounds that you see your users doing and it’s counterproductive,” she said, “that is not a learning problem. It’s a design problem.”
Morelli split the same distinction into noise and behavior. The noise is questions: how do I find this, how do I do that within the system. That is discomfort, and it passes. The workaround is behavior, and it is diagnostic. “Are you finding that your team now has three new spreadsheets to try to manage the tool that you just implemented?” he asked. “Because that tool is falling short.”
Kurth supplied the sharpest test, from having been the person in question. “Is there someone that is holding it all together?” she said. “I’ve been that person in a company who I’m making the product work because I’m fixing everything that people are doing. I’m following up after them, reminding them how to use it. That’s not adoption, and that’s not a successful implementation.” Most organizations read that employee as indispensable. The panel reads them as a patch over a rollout that did not take.
How to Get Honest Feedback on New Software Before It Becomes a Resignation
Every panelist agreed that leaders hear about failures late, and disagreed only about the mechanism for hearing earlier. Donaldson’s position is that the groundwork happens long before any purchase. “You have to be a good leader first. You have to encourage feedback,” he said, otherwise nothing surfaces regardless of the tool. Kurth’s addition is that vague solicitations get vague answers, and she recommends a structured prompt: start, stop, continue, or simply asking what is working, what is not, and what people wish they could do. Teams asked a specific question, she said, get enthusiastic about answering it.
Burst pointed out that the loops are plural: administrative staff and technicians use the same platform differently, so one feedback channel captures one experience and misses the other. Both should go back to the vendor as evidence rather than complaint.
Morelli cautions against overreacting to the wrong signal, reaching for a 2006 case: when Facebook launched its news feed, roughly a million of its ten million users protested, organizing through the feature they were protesting, and the company held because usage said something the noise did not. Leaders have to decide in advance which measure counts as the verdict.
Software Implementation Has a Goal, Not a Countdown
Morelli’s framing for what goes wrong before any of that is a scheduling error disguised as a plan. “Implementation should never have a countdown. It should have a goal,” he said, comparing the countdown mentality to hiring a marketing lead and expecting marketing to be solved five days after the start date. He prefers to call the whole exercise implementation plus calibration, on the grounds that a system can be technically implemented and still not calibrated to the organization running it.
Veerappan’s addition is that measurement happens afterward: adoption rate, feature usage, and what support looks like once the rollout team leaves. Burst offered the owner’s heuristic, half joking: you stop hearing about the ones that worked.
The Workflow Metric Underneath Every ABA Staffing Complaint
Morelli’s challenge to the room was a single number most operators cannot produce: how many minutes of administrative and technology work does it take to support one hour of clinical care? Without it, he argued, an organization cannot honestly diagnose a staffing shortage, because it does not know whether it needs more people or less work. His supporting logic is that burnout varies too much between organizations to be a property of the field. “Death by 1000 clicks is still death,” he said. “You just may not assign sort of a certificate against it.” Acuity has argued the same thing from the data side, that the ABA workforce shortage behaves like a retention problem rather than a recruitment one.
His preferred retention indicator is blunter than anything on a dashboard. “I really think about my north star as like a reduction in pajama time,” he said: whether staff have stopped taking work home at night. It is a soft metric for a hard market. Inside a buy-and-build platform, a single software decision propagates across every site the sponsor owns, and the operational mistakes that break multi-site growth tend to be the ones nobody priced.
Smaller practices absorb the same fixed compliance and technology costs with none of the scale, which is part of why their closures leave almost no public record. The panel’s argument, made by the people selling the workflows, is that operators have more leverage over these decisions at the contract stage than at any point afterward, and mostly do not use it.
