Post: How Nick Cut 6 Manual Handoffs From Proposal Generation With One Make Workflow
Proposals should close deals. Instead, they were eating Nick’s team alive.
Nick runs a small recruiting firm with a team of three. Like a lot of professional services operations, his proposal process was held together with copy-paste, calendar reminders, and someone remembering to follow up. If you’ve been tracking our work on how Make scenarios are reshaping recruiting and ops workflows, Nick’s situation is exactly the kind of case we had in mind — high-touch process, low automation maturity, and a team too small to absorb the waste.
Before we touched his stack, generating one proposal took three days and six distinct manual handoffs. After one Make workflow, proposals go out the same day — triggered automatically when a deal stage changes in his CRM. Here’s how it came together.
| Client: | Nick — Recruiter, small firm (team of 3) |
| Industry: | Professional services / recruiting |
| Problem: | 6 manual handoffs, 3-day proposal cycle |
| Solution: | Single Make workflow triggered by CRM deal stage |
| Result: | Same-day proposals; 15 hrs/week reclaimed; 150+ hrs/month across team |
| Key dependency: | CRM data hygiene |
What Was Actually Happening Before the Build?
Nick’s pre-automation proposal process looked like this: a recruiter closes an intro call, flips a deal stage in the CRM, then manually notifies a colleague to pull client details. That colleague copies the relevant fields into a Word template, fills in the fee structure, saves it as a PDF, emails it to Nick for review, waits for edits, resaves, then sends. Six steps. Six opportunities for delay, error, or the file to sit in someone’s inbox over a long weekend.
Three days was the average. On a bad week it was five. In recruiting, that kind of lag matters — candidates don’t wait, and neither do clients who are evaluating multiple firms.
The team wasn’t doing anything wrong. The process was just never designed for speed. It was designed by accumulation — each step added over time because someone needed something, and nobody ever stepped back to map the whole thing. If you want a framework for that kind of audit, these seven questions are worth running through before you build anything.
When we mapped it, the six handoffs broke down like this:
- Recruiter updates CRM deal stage
- Recruiter manually notifies ops colleague
- Colleague pulls client data from CRM
- Colleague populates proposal template
- Draft routed to Nick for review
- Nick approves, colleague sends final to client
Steps 2 through 6 were all candidates for elimination or automation. Step 1 — the deal stage update — became the trigger.
What Did the Approach Look Like Before We Built Anything?
We don’t build first. We map first. That’s the OpsMap™ step — understanding the process as it actually runs, not as someone thinks it runs.
In Nick’s case, the map revealed two things fast. First, the handoffs weren’t adding value — they were compensating for a system that couldn’t move data on its own. Second, the data was already in the CRM. Client name, contact info, fee structure, engagement type — all of it was there. The team just had no way to pull it without human hands in the loop.
The question wasn’t whether to automate. It was whether the CRM data was clean enough to trust as a source. That’s a non-negotiable caveat with any proposal automation: if the CRM fields are inconsistent or half-empty, the workflow will produce garbage proposals. We confirmed the data hygiene was solid before we wrote a single module. If you want to run that kind of pre-build check on your own stack, this OpsMap audit process walks you through it.
Once we had confidence in the data, the design was straightforward: watch the CRM for a specific deal stage, pull the client record, populate a proposal template, route it for one-touch review, and send. No manual notification. No copy-paste. No file hand-carrying.
How Did the Make Workflow Actually Get Built?
The Make scenario runs as a linear workflow with a conditional review gate. Here’s the structure:
Trigger: CRM watch module fires when a deal moves to the target stage. This is the only manual action required — the recruiter updates the deal, same as always. Everything after that is automated.
Data pull: The scenario retrieves the full client record — name, contact details, fee structure, engagement type, and any custom fields that feed the proposal. Because the CRM fields are mapped consistently, there’s no guesswork. The data arrives clean.
Proposal generation: Make populates a proposal template using the retrieved fields. We used a document tool connected via API — no native module required. The HTTP module handled the API call, with the JSON payload formatted precisely. This is the kind of task that used to require significant back-and-forth to get right; with a well-seeded Make environment, it came together faster.
Review gate: Rather than sending blind, the scenario routes the generated proposal to Nick via a Slack notification with a direct link. One click to approve, one click to flag for edits. This preserves human judgment without requiring Nick to be in the weeds of document assembly.
Send: On approval, Make sends the proposal to the client contact pulled from the CRM record. The deal stage updates automatically to reflect sent status. The recruiter gets a confirmation. Done.
The entire workflow replaced handoffs 2 through 6. The only human steps that remain are the initial deal stage update (handoff 1) and the one-touch review. Everything else runs without anyone in the loop.
This is similar in principle to what we built for David’s team — where manual data transcription between systems was creating costly errors. That case study shows how automating data movement eliminates a whole category of risk, not just time.
What Changed After the Workflow Went Live?
The numbers tell most of the story:
| Metric | Before | After |
|---|---|---|
| Manual handoffs per proposal | 6 | 1 (review gate only) |
| Average time to send proposal | 3 days | Same day |
| Time reclaimed per recruiter per week | — | 15 hrs |
| Time reclaimed across team per month | — | 150+ hrs |
| Proposal errors due to copy-paste | Recurring | Eliminated |
The speed improvement was the headline, but the error reduction was arguably more valuable. When a human copies client data from a CRM into a Word document, mistakes happen. Wrong fee, wrong contact name, wrong engagement terms — each one creates a confidence problem with the client before the relationship even starts. The Make workflow pulls directly from the source. If the CRM is right, the proposal is right.
Nick’s team also reported a secondary benefit they didn’t anticipate: because proposals now go out the same day, they’re reaching clients while the conversation is still warm. Closing speed improved. They’re not tracking it to a dollar figure, but the pattern is consistent.
What Are the Honest Lessons From This Build?
A few things worth naming clearly for anyone thinking about a similar build:
Data hygiene is the real prerequisite. This workflow is only as reliable as the CRM data feeding it. We confirmed field consistency before building. If Nick’s CRM had patchy data — missing fields, inconsistent naming conventions, fee structures stored in notes instead of mapped fields — the workflow would have generated unusable proposals. Clean data first, automation second. Always.
The review gate is a feature, not a compromise. Some operators want full automation — no human in the loop at all. For proposal generation, we don’t recommend it. The one-touch review takes Nick about 30 seconds. It catches anything the CRM data didn’t anticipate — a custom arrangement, a verbal agreement that didn’t make it into the record yet. Keeping a human checkpoint on client-facing output is good ops, not a weakness in the build.
The trigger design matters as much as the workflow itself. We spent real time on what constitutes the right trigger — which deal stage, which conditions, what happens if the stage is updated in error. Getting the trigger logic right prevents the scenario from firing on the wrong records or firing twice. Sloppy triggers create more manual work, not less.
Six handoffs is not unusual. When we show clients the mapping of their current process, they’re often surprised at the count. Nobody designed six handoffs intentionally. They accumulated. The value of the OpsMap step is making that visible before you decide what to automate.
Information in this article is deemed to be accurate at time of publishing. 4Spot Consulting reviews and updates content periodically as best practices evolve.
