How We Built 300+ Automations for a Single Healthcare Company

Horizons ABA is an Applied Behavior Analysis therapy company that was growing fast and breaking at the seams. When they came to us, their team was drowning in manual work -- copying data between systems, chasing approvals, coordinating schedules across dozens of clinicians, and spending hours on tasks that should take minutes.

Over 845 hours of project work, we built 300+ Make.com scenarios and 200+ Monday.com automations that now run their operations. This is how we did it.

The Starting Point

ABA therapy companies have a uniquely complex operational model. Every client (typically a child) needs a treatment plan approved by insurance. Each plan requires specific clinician assignments based on credentials, availability, location, and specialization. Sessions need to be scheduled, documented, billed, and tracked for compliance. Multiply that by hundreds of active clients and dozens of clinicians, and you have a coordination nightmare.

Horizons was managing most of this manually. Spreadsheets, emails, copy-paste between platforms, and a lot of tribal knowledge in the heads of operations staff. The team was growing, but the manual processes were not scaling with them. New hires took weeks to get up to speed because the processes lived in people's heads, not in systems.

They needed automation, but not just a few workflows here and there. They needed an operational backbone.

Architecture Decisions

Before building a single automation, we spent time understanding the full picture. What systems were already in place. Where data lived. How processes actually worked (not how they were documented, but how people actually did them day-to-day).

We made several key architecture decisions early on.

Make.com as the automation engine. The volume and variety of workflows made Make.com the right choice. We needed to connect multiple systems -- their EHR (Electronic Health Record), Monday.com for project management, Google Workspace, communication tools, billing platforms -- and Make.com's connector library covered nearly all of them.

Monday.com as the operational hub. Rather than building custom dashboards, we used Monday.com as the interface where the operations team actually works. Boards for client intake, clinician management, scheduling, compliance tracking, and billing. The team interacts with Monday.com. The automations run behind it.

Separation of concerns. Each automation handles one specific job. We do not build monolithic workflows that try to do everything. A client intake automation handles intake. A scheduling automation handles scheduling. They communicate through shared data, not through being chained together in one massive scenario.

Idempotency by default. In healthcare, duplicate actions are dangerous. A duplicate billing submission or a duplicate session record creates real problems. Every automation we build checks whether its action has already been performed before executing. This means if a scenario runs twice on the same trigger, it does not create duplicate records.

Organizing 300+ Scenarios

At 300+ scenarios, organization is not optional. It is the difference between a system you can maintain and a system that collapses under its own weight.

Naming conventions. Every scenario follows a strict naming pattern: [System] - [Process] - [Action]. For example, EHR - Client Intake - Create Monday Item or Monday - Scheduling - Sync to Google Calendar. When you are looking at a list of 300 scenarios, you need to find the right one in seconds.

Folder structure. Scenarios are grouped into folders by business function: Intake, Scheduling, Billing, Compliance, HR, Communications, Reporting. Each folder maps to a department or process area.

Documentation in the scenarios. Every scenario has notes on the first module explaining what it does, when it triggers, and what downstream systems it affects. When someone opens a scenario six months later, they do not need to reverse-engineer it.

Version tracking. Make.com does not have built-in version control in the way code does. We maintain a changelog document for each major process area that tracks what changed, when, and why. When something breaks, we can trace back to the last change.

The Monday.com Layer

Monday.com is not just a project management tool in this setup. It is the operational interface. The 200+ automations on the Monday.com side handle the internal workflow -- status changes, notifications, assignments, due dates, and board-to-board data movement.

Client lifecycle boards. A client moves through stages: referral, intake, assessment, authorization, active treatment, discharge. Each stage has its own automations that trigger the right actions -- notify the intake coordinator, create assessment tasks, submit authorization requests, assign clinicians.

Clinician management. A board tracks every clinician's credentials, availability, caseload, and location. When a new client needs a clinician match, automations flag available clinicians based on the client's needs and the clinician's profile.

Custom internal tools. We built several internal tools on top of Monday.com using its API. A scheduling optimizer that factors in clinician availability, client preferences, travel time, and authorization limits. A compliance tracker that flags upcoming credential expirations or missing documentation before they become problems.

The Monday.com automations and the Make.com scenarios work together. Monday.com handles the in-platform workflow. Make.com handles the cross-platform data movement and complex logic that Monday.com's native automations cannot handle.

Monitoring at Scale

300+ automations fail. That is not pessimism, it is reality. APIs go down. Data comes in malformed. Rate limits get hit. External systems change their schemas without warning. The question is not whether failures happen but how fast you catch and fix them.

Error routing. Every Make.com scenario has error handling built in. When a scenario fails, it does not just log an error in Make.com's interface. It sends a structured alert -- Slack message with the scenario name, the error type, the data that caused the failure, and a direct link to the scenario for debugging.

Health monitoring. We run daily health checks that verify critical automations executed within their expected timeframes. If the morning billing sync did not run by 9 AM, we know about it by 9:05 AM.

Execution dashboards. We track execution volumes, error rates, and processing times. When a scenario that normally takes 10 seconds starts taking 60 seconds, that is an early warning sign of an API issue or data problem.

Staged rollouts. When we update a critical automation, we do not just push it live. We clone the scenario, test with real data in a controlled way, verify the output, then swap it in. The old scenario stays available as a rollback option.

Maintenance Reality

Maintaining 300+ automations is ongoing work. Here is what that looks like in practice.

Weekly reviews. We review error logs and execution data weekly. Most issues are transient -- an API timeout that resolved itself, a one-off data format issue. But patterns in errors often reveal upstream problems that need fixing.

Change management. When Horizons changes a process (new intake form fields, new billing codes, new compliance requirements), we update the affected automations. The folder structure and naming conventions make it straightforward to identify which scenarios need changes.

Platform updates. Make.com and Monday.com both update their platforms regularly. New features, deprecated endpoints, changed behaviors. We stay on top of these and proactively update scenarios before deprecated features break them.

Scaling. As Horizons grows (more clients, more clinicians, more locations), the automation volume grows with them. We have built the architecture to handle this. Adding a new location means configuring the existing automations with new parameters, not building from scratch.

Lessons Learned

Start with process, not technology. We spent significant time mapping processes before building anything. The automations that work best are the ones built on a clear understanding of what actually needs to happen, not what someone thinks should happen.

Small automations beat big ones. A single scenario that handles an entire process is fragile and hard to debug. Twenty small scenarios that each handle one step are resilient and easy to maintain. When one fails, the others keep running.

Documentation is not optional at scale. At 10 automations, you can keep it in your head. At 300, you cannot. Every hour spent documenting saves ten hours of debugging later.

Healthcare requires extra care. Data accuracy, HIPAA considerations, audit trails -- healthcare automation has higher stakes than automating a marketing workflow. We build accordingly, with validation checks, error handling, and idempotency baked into every scenario.

The operations team needs to understand the system. We do not build black boxes. The Horizons operations team knows how their automations work, can identify issues, and can request changes with specificity. That is by design.

The Result

845 hours of build time. 300+ Make.com scenarios. 200+ Monday.com automations. A healthcare company that runs its operations through automated systems instead of spreadsheets and emails.

The manual work that used to consume the operations team's days now runs in the background. Intake processing that took hours happens in minutes. Scheduling that required back-and-forth emails happens automatically. Compliance tracking that relied on someone remembering to check a spreadsheet now sends proactive alerts.

This is what automation looks like when it is done at scale, with discipline, for an industry where mistakes have real consequences.

If your operations team is spending their days on repetitive coordination work, there is a better way. Book a Free Discovery Call and we will look at where automation fits in your business.