Automation Intake Pack sample filled example
This page is a worked example built to show the pack in use. It is intentionally fictional and exists to make the paid templates feel tangible without inventing testimonials or fake results.
Fictional sample example
Website inquiry to proposal routing for a small service business
This is a fictional worked example built to show how the pack can be filled out. It is not a client story, testimonial, or promised result.
A three-person B2B services agency wants faster follow-up on warm website inquiries and a cleaner handoff from first form submission to scoped proposal draft.
How to use this page
This example is here to show the finished shape of the pack in use. It should help a buyer picture the workflow without pretending this is a real client or a guaranteed result.
From `client-intake-questionnaire.md`
Filled intake snapshot
Company / brand
Sample B2B services agency (fictional)
Primary contact
Operations lead
Role / title
Co-owner
Industry / niche
B2B services
Team size touching this workflow
3 people
Primary decision-maker
Two co-founders
Target timeline or deadline
Phase 1 ready before next month
Main communication channel
Email + Slack
What triggered the project
Sample response notes
- New website inquiries come through a Webflow form and land in a shared Gmail inbox.
- The ops lead still copies qualified details into HubSpot by hand and pings the founder in Slack.
- If nothing changes, warm leads keep getting slower replies and proposals stay inconsistent from call to call.
- Success means every qualified inquiry is acknowledged within 15 minutes and a proposal draft is ready the same day as the discovery call.
From `workflow-mapping-worksheet.md`
Current-state map snapshot
The paid file uses the same table shape. This sample just fills it out with one fictional scenario so a buyer can see the level of detail.
| Step | Trigger / input | Owner | Tool / system | Output | Pain / risk | Automation opportunity |
|---|---|---|---|---|---|---|
| 1 | Webflow form submitted | Ops lead | Webflow + Gmail | Inquiry hits shared inbox | Inbox pileups delay first response | Create CRM record and alert the team instantly |
| 2 | Ops reviews project type and budget range | Ops lead | HubSpot | Lead is tagged as qualified or not yet ready | Tagging rules are inconsistent across team members | Pre-fill qualification score from form fields and route edge cases for review |
| 3 | Qualified lead needs a discovery call | Founder | Slack + Calendly + Gmail | Scheduling link and intake questions are sent | Founder sends different follow-up notes every time | Send a standard follow-up with the right intake prompts and internal Slack context |
| 4 | Discovery call ends | Founder | Call notes + Google Docs | Proposal draft is prepared | Notes are messy and proposal scope gets rewritten from scratch | Turn structured notes into a proposal-ready summary draft with human approval before send |
From `permissions-risk-checklist.md`
Permissions and launch notes
Access and environments
ConfirmedHubSpot, Gmail, Slack, and Google Docs access can be granted through workspace accounts instead of personal logins.
Data sensitivity
Confirmed with limitsThe workflow handles client contact details and pricing context, so proposal drafting still needs a human review before anything is sent.
Failure handling
Required controlIf routing fails, Slack should alert the ops lead and the shared inbox remains the manual fallback.
Launch gate
Not allowed to skipNo automated proposal or quote should go directly to the prospect without founder approval.
Risk register example
What honest scoping looks like
| Risk | Impact | Likelihood | Mitigation | Owner | Status |
|---|---|---|---|---|---|
| Low-quality or duplicate inquiries create noisy CRM records | Medium | Medium | Require core fields, dedupe by email, and route weak submissions to manual review. | Ops lead | Open |
| Proposal draft includes the wrong service tier or pricing language | High | Medium | Keep pricing and final proposal approval fully human-reviewed. | Founder | Required control |
| Slack alerts become noisy and get ignored | Medium | Low | Only alert the team on qualified leads and route low-fit inquiries to a digest. | Automation builder | Planned |
From `proposal-ready-summary-template.md`
Proposal-ready summary excerpt
Problem statement
The agency has enough inbound demand to justify a cleaner intake system, but the current process depends on an ops person copying form details, a founder re-reading scattered notes, and a proposal draft getting rebuilt from scratch after each call. The result is slower follow-up and inconsistent scope language right when the lead is warm.
Proposed outcome
Phase 1 should create a repeatable intake path: new inquiries are logged automatically, qualified leads trigger a standard follow-up and internal alert, discovery notes move into a proposal-ready summary, and every outbound proposal still stays human-approved.
Recommended stack
Make for routing and notifications, HubSpot as the source of truth, Slack for internal alerts, and Google Docs for the human-reviewed proposal draft.
Human review points
A founder still approves qualification edge cases, service tier selection, and every final proposal before it goes out.
Recommended offer
Scoped phase 1 build after validation
Proposed next action
Approve the phase 1 scope, share sample form submissions, and confirm the Slack + HubSpot owners before build starts.
Sample phase 1 scope
- Capture website inquiries into HubSpot with the required fields already normalized.
- Alert the internal team in Slack only when the inquiry matches agreed qualification rules.
- Send a consistent intake follow-up with scheduling and discovery questions.
- Create a proposal summary draft from the structured notes after the call, with human approval before send.
Out of scope for phase 1
- Fully automated pricing or quote generation.
- Replacing HubSpot with a new CRM.
- Any workflow that sends proposals without founder review.
| Phase | Outcome | Estimated timing |
|---|---|---|
| Discovery / validation | Confirm fields, scoring rules, and approval path | 2-3 business days |
| Build / configuration | Set up routing, alerts, and draft generation flow | 4-5 business days |
| Testing / revisions | Run sample submissions and tighten edge cases | 2 business days |
| Launch / handoff | Move into production with fallback notes and owner handoff | 1 business day |
Light usage guidance
How to adapt the real files after purchase
Replace the systems, not the logic
Swap Webflow, HubSpot, Slack, and Google Docs for the buyer's actual stack, but keep the same discovery sequence: trigger, owners, pain points, approvals, and first automation opportunity.
Leave risk notes honest
If access, data handling, or failure ownership is still unclear, keep those rows open instead of filling them optimistically. The pack works best when it prevents bad scope promises.
Use the proposal last
Only turn the notes into a client-facing summary after the questionnaire, workflow map, and risk check are complete. That order is what keeps the proposal grounded.