How I automated my Intake Meeting process end-to-end (RecOps/HR use case): one trigger, three outputs

Knowledge Hub
,
1

Hi everyoner, first-time poster.

I’m a Technical Talent Partner, and over the past few months I’ve been building out Make workflows for recruiting/RecOps use cases. Wanted to share the biggest one, since it’s saved my team hours per new role setup and I think the pattern is reusable well beyond HR.

Article here

The problem

Every hiring manager intake meeting produces the same three follow-ups: brief the recruiting/sourcing team, prep a screening kit for interviewers, and update the job description with whatever changed in the conversation. Doing this by hand after every intake call was the bottleneck, not the meetings themselves.

The shape of the workflow

One trigger, one shared processing path, three independent branches that don’t depend on each other:

Trigger → Common processing (“the trunk”) → Branch A / Branch B / Branch C

If one branch fails, the other two still complete. That independence turned out to matter more than I expected, more on that below.

Step one: the common path

  1. Trigger — Google Drive watches a folder every 15 minutes for new files.
  2. Filter — only files named “Intake Meeting” get processed (everything else is ignored at this stage).
  3. Extraction — downloads the meeting summary as Markdown (to preserve links) plus the transcript if one exists.
  4. AI analysis — an LLM (I’m using Claude) extracts structured data from the raw notes: hiring manager, role, must-have skills, department, team context.
  5. Parsing — converts that response into clean, usable fields for the rest of the scenario.
  6. Generation — a second AI step turns the structured data into a screening kit: skills to probe, suggested questions, red flags, recommendations for interviewers.

Everything downstream reads from this one pass — nothing gets re-extracted or re-analyzed per branch.

Branch A — Slack

Creates a private Slack channel for the role, posts a welcome message and hiring recap, threads a sourcing brief underneath it, and auto-invites the hiring manager. One detail I’m oddly proud of: an accent-stripping step before matching names against Slack usernames, because name-matching across systems breaks constantly otherwise.

Branch B — Screening kit (Notion)

Takes the screening kit generated in the trunk, creates a Notion page with it, and drops a link to it in the Slack channel from Branch A.

Branch C — JD v2

Searches the calendar for the original intake event, pulls the existing job description from Notion, and generates an updated version that flags what changed and where the JD is inconsistent with what was actually said in the meeting.

What I’d flag for anyone building something similar

Fallbacks matter more than the happy path. I added Resume modules at a few failure-prone points (API rate limits, a missing transcript, a Notion page that already exists) specifically so one branch failing doesn’t take down the other two. Given three independent outputs from one trigger, that isolation is the whole point of the architecture — don’t skip it.

The system doesn’t create judgment, it amplifies it. If the intake conversation itself is thin, the screening kit and JD update will be thin too, no matter how good the AI step is. This isn’t a Make problem, it’s a garbage-in-garbage-out problem — worth setting expectations on before you sell this internally as “AI will fix our intake process.”