Post: How a Non-Technical HR Team Started Building Their Own Automations With Make + AI
Results at a Glance
| Metric | Before | After (90 days) |
|---|---|---|
| Automations built by HR team | 0 | 7 |
| Partner dependency for workflow changes | Every change | Changes under 30 min: self-serve |
| Admin hours reclaimed per week | — | 12 hrs (Sarah: 12 hrs/week) |
| Hiring process time | Baseline | Cut 60% (Sarah) |
| Average time to build a new automation | N/A (partner-dependent) | 35 minutes with Claude |
This case study covers what happened when an HR Director at a regional healthcare organization — a non-technical operator managing a team of three — gained the ability to build and modify her own Make (get a free month of Make with 10K free actions here) automations using Claude and the Make MCP server. The results after 90 days changed how we describe the adoption barrier for Make to every new client we talk to.
The broader context for why Make’s AI integration makes this possible is in the Make vs Zapier vs N8N Complete 2026 Guide. This post documents what it looked like in a real HR operations environment.
Context: An HR Director Who Couldn’t Touch Her Own Automations
Sarah is an HR Director at a regional healthcare organization. Her team manages recruiting, onboarding, compliance tracking, and benefits administration across multiple facilities. She had been using Make for 14 months before this engagement — a 4Spot partner had built her initial automation stack, and it ran well.
The problem: any change to an existing scenario required opening a support ticket. Small changes — updating a Slack notification message, adding a new hiring manager to a routing scenario, changing a status trigger threshold — waited days to weeks depending on the partner’s availability. Sarah knew exactly what she wanted. She had no way to implement it herself.
The backlog of “small changes waiting on the partner” had grown to 11 items. Several had been waiting for over a month. The automations still ran correctly on the original logic — but the business had changed and the workflows hadn’t kept up.
Approach: MCP Server Access + Structured Onboarding
We set up the Make MCP server in Claude on Sarah’s laptop. Two hours of structured onboarding covered:
- How to connect to her Make account via the MCP server
- How to describe an automation change to Claude clearly enough to get a usable result
- How to review a blueprint before importing it
- How to test with Make’s “Run once” function
- When to escalate to the partner vs. handle independently
The onboarding included three live exercises: Sarah described each change to Claude, reviewed the output, and imported and tested it herself. All three ran on the first test attempt.
We defined the scope of self-service clearly: scenario modifications and new simple scenarios (one trigger, two to four action modules) were self-service. Multi-scenario architecture, API integrations with complex auth, and anything touching compliance workflows stayed in partner scope.
Implementation: The First 90 Days
Sarah cleared her 11-item backlog in three sessions over the first two weeks. Average time per change: 22 minutes, including the time to write the description, review Claude’s output, and test.
Over 90 days, she built seven new automations independently:
- Applicant status update → hiring manager Slack notification with applicant name and role
- New hire paperwork completion → task creation in the HR project management tool
- Benefits enrollment deadline approaching → automated reminder email to employees with open enrollment
- I-9 expiration tracking → 30-day advance Slack alert to HR coordinator
- Exit interview scheduling → Calendly link triggered on termination record creation in HRIS
- Weekly headcount report → scheduled data pull from HRIS to Google Sheet
- Job posting go-live → LinkedIn share notification to the recruiting coordinator
All seven were within the defined self-service scope. None required partner involvement.
Results: What Changed in 90 Days
The quantified results matched what we track for HR automation implementations: 12 hours per week reclaimed, hiring process time cut 60%. Those numbers came from the reduction in manual status updates, reminders, and data transfers the automations replaced.
The qualitative shift was more significant. Sarah’s relationship with her automation stack changed from passive (“it runs, I don’t touch it”) to active (“it runs, and I can change it when the business changes”). That shift eliminated the feedback loop problem that had left 11 small but meaningful changes waiting for months.
Two observations from Sarah 90 days in: “I spend about 30 minutes a week on automation maintenance now, and I do it myself. Before, I wasn’t doing it at all because the ticket process wasn’t worth it for small things. Now small things get done.” And: “I built the I-9 expiration tracker in 28 minutes. I’ve been meaning to build that for two years.”
Lessons Learned
Scope definition matters. The clear line between self-service and partner scope prevented Sarah from attempting architecturally complex scenarios that would have frustrated her and damaged her confidence. Starting with changes and simple new scenarios built fluency before tackling anything harder.
The two-hour onboarding was sufficient. Technical training was not needed. The onboarding was about prompting practice — how to describe an automation change clearly. That skill transferred to every subsequent interaction with Claude.
The backlog metric is the hidden cost of partner dependency. Eleven items waiting was not unusual — it was the norm. Every HR operations team has a list of “things that would help if we could automate them, but we never get around to it.” The MCP server turned that list into a work queue instead of a wishlist.
The full how-to for building Make automations with Claude is at How to Build a Make Automation in Plain English Using the MCP Server.
Expert Take
The automation-first principle applies to the adoption model too. The systems Sarah uses every day — Make, Claude, Slack — did not change. The MCP server connected them in a way that made her existing workflow the interface for building automation. She did not learn a new tool. She learned a new use for a tool she already had. That is adoption by design. When the front end looks like what you already do, resistance disappears.
Information in this article is deemed to be accurate at time of publishing. 4Spot Consulting reviews and updates content periodically as best practices evolve.
RELATED POST
