Most teams treat client onboarding as a feature shopping problem. The default response to “our onboarding is messy” is: “Which CRM should we buy?”
This is backwards.
Tools don’t fix unclear processes. They just automate unclear processes faster. A $200/month CRM won’t solve handoff failures, lost context, or ad-hoc communication. It will just give you an expensive place to store the same problems.
I wanted to prove a different hypothesis: if you design the process correctly, free tools are sufficient.
This post documents how I built a complete, end-to-end client onboarding system using only free tools and clear process thinking. No CRMs. No paid onboarding platforms. No contract management SaaS. No monthly subscriptions.
Total cost: $0.
The Onboarding Problem Space
Client onboarding in a service business touches multiple domains simultaneously:
- Lead intake — Inquiries come from multiple channels (email, referrals, cold outreach, inbound)
- Discovery — Understanding the problem, assessing fit, internal alignment on approach
- Proposal creation — Scope, timeline, pricing, revisions based on feedback
- Agreements — Contracts, invoices, approvals, legal artifacts
- Communication — Distributed across WhatsApp, email, calls, async updates
- Documentation — Context retention for long-term client relationships
The failure modes are predictable:
- Unclear handoffs — Who owns what step? When does discovery end and proposal begin?
- Lost context — Client mentioned constraints in a WhatsApp message three weeks ago. Where is it now?
- No single source of truth — Is the latest scope in the email, the Drive doc, or the ClickUp task?
- Ad-hoc communication — Client asks questions via WhatsApp. Answers go in email. Decisions documented nowhere.
Most teams respond to this by buying more software. A CRM for lead tracking. A proposal tool for scoping. A contract platform for agreements. A project management tool for execution.
Now you have six tools, six sources of truth, and six places where context gets lost.
The real problem isn’t missing tools. It’s missing process.
Design Principles
Before choosing any tools, I defined what the system needed to do:
1. One Source of Truth
All critical client context must live in one place. Not scattered across email threads, chat logs, and Google Docs. One canonical location where the full history—decisions, constraints, artifacts, communication—is centralized.
2. Clear Separation of Concerns
Each tool has one job:
- Documentation ≠ Task management
- Communication ≠ Decision tracking
- File storage ≠ Process definition
If a tool tries to do everything, it does nothing well. Keep responsibilities narrow.
3. Explicit Process Over Tribal Knowledge
If a step is important, it must be written down. No “we just know how onboarding works.” If a team member leaves, the system should still function. If I need to hand off a client mid-onboarding, the next person should have everything they need in the documentation.
4. No Paid SaaS Dependency
The system should work even if every paid tool disappears tomorrow. This isn’t about being cheap—it’s about resilience and portability. Paid platforms change pricing, get acquired, shut down. Free tools with open standards (markdown, email, files) last decades.
The Stack (All Free)
I assembled the system from tools that already exist and have free tiers sufficient for real work:
Obsidian → Documentation & Source of Truth
Role: Central repository for all client context.
Every client gets a note in Obsidian. That note contains:
- Initial inquiry details
- Discovery call notes
- Constraints, goals, budget
- Proposal versions and client feedback
- Agreement status, invoice details
- Ongoing project context and decisions
Why Obsidian:
- Free (one-time purchase, no subscription)
- Local-first (I own the data)
- Markdown (portable forever)
- Backlinks (see all references to a client across notes)
- Search (instant full-text search across all clients)
Google Drive → Selective File Sharing
Role: File and document sharing with clients.
When a client needs a proposal, contract, or deliverable, it goes in a shared Drive folder. But Drive is not the source of truth. It’s just a distribution channel.
The actual proposal content is written in Obsidian first, then exported to Drive as PDF or Google Doc for client access.
Google Meet → Discovery & Alignment Calls
Role: Synchronous discovery and scoping conversations.
Free tier: 60-minute calls, sufficient for discovery. Notes from every call go into the client’s Obsidian note immediately after the call.
WhatsApp → Primary Client Communication
Role: Async client communication for most interactions.
Clients prefer WhatsApp. It’s where they live. So that’s where initial questions, quick clarifications, and status updates happen.
Critical rule: Every important decision or piece of context from WhatsApp gets copied into the client’s Obsidian note. WhatsApp is the communication channel, not the archive.
Discord → Internal Team Discussions
Role: Internal async coordination and optional client syncs.
For team discussions about client projects. Some clients also join a private Discord channel for ongoing communication (their preference).
Internal-only channels: private. Client channels: optional based on client preference.
ClickUp (Free Tier) → Task Execution Only
Role: Task tracking during project execution.
ClickUp is not used for onboarding process management. It’s only used once the client is onboarded and we’re executing deliverables. Tasks, deadlines, dependencies—that’s it.
Why not use ClickUp for onboarding? Because onboarding is a linear process with context. Task managers are bad at preserving context. Obsidian is better.
The Onboarding Process
With tools mapped to responsibilities, here’s the actual workflow:
Stage 1: Lead Intake
Trigger: Inquiry via email, referral, or inbound.
Actions:
- Create client note in Obsidian (
clients/client-name.md) - Log: source, initial message, date, key details
- Template includes sections: Background, Goals, Constraints, Budget, Timeline, Fit Assessment
Artifacts: Client note created, initial context captured.
Handoff: To discovery stage if fit looks good. Otherwise, polite decline with reasoning documented.
Stage 2: Discovery Call
Trigger: Lead assessment shows potential fit.
Actions:
- Schedule Google Meet
- Conduct 30-60 min discovery (use discovery question template)
- Take structured notes during call
- Immediately after call: update client note with:
- Problem definition
- Constraints (technical, budget, timeline)
- Success criteria
- Internal fit assessment
Artifacts: Discovery notes in client Obsidian note.
Handoff: If fit confirmed → proposal stage. If not → document reasoning, archive.
Stage 3: Proposal Creation
Trigger: Discovery complete, fit confirmed.
Actions:
- Draft proposal in Obsidian using proposal template
- Sections: Problem, Approach, Scope, Timeline, Pricing, Terms
- Internal review (if team project)
- Export to PDF or Google Doc
- Share via Google Drive with client
- Log: proposal sent date, version number
Artifacts:
- Proposal document in Drive
- Proposal text + metadata in Obsidian
Handoff: Await client feedback. Revisions loop back to this stage. Approval moves to agreement.
Stage 4: Agreement & Payment
Trigger: Client approves proposal.
Actions:
- Prepare agreement document (contract template)
- Share via Google Drive for signature (or use free DocuSign alternative)
- Send invoice (manual, via email, or Stripe payment link)
- Log: agreement signed date, invoice sent, payment received
- Update client note with payment details
Artifacts:
- Signed agreement in Drive
- Invoice record in Obsidian
- Payment confirmation logged
Handoff: Payment confirmed → onboarding complete, project execution begins.
Stage 5: Project Execution Handoff
Trigger: Agreement signed, payment received.
Actions:
- Create project in ClickUp (now tasks become relevant)
- Link ClickUp project back to Obsidian client note
- Kick-off call (Google Meet) to align on execution
- Ongoing context continues to accumulate in Obsidian note
- Tasks live in ClickUp, decisions and context live in Obsidian
Artifacts:
- ClickUp project with tasks
- Kick-off notes in Obsidian
- Shared Drive folder for ongoing deliverables
What This Looks Like in Practice
Example: Client “Acme Corp”
Obsidian Note Structure:
# Acme Corp
## Metadata
- Source: Referral from Jane Doe
- Industry: SaaS / B2B
- Initial Contact: 2025-02-15
- Status: Active Project
- ClickUp: [Link to project]
## Background
[Initial inquiry details, company context]
## Discovery Call (2025-02-16)
**Attendees:** John (Acme CTO), Me
**Problem:** Need to redesign onboarding flow, current conversion is 40%, target 70%
**Constraints:**
- Budget: $15K
- Timeline: 6 weeks
- Tech stack: React, Next.js
**Goals:**
- Increase activation rate
- Reduce time-to-value
- Better onboarding analytics
## Proposal
**Sent:** 2025-02-18 (v1)
**Feedback:** Wants to add user research phase
**Revised:** 2025-02-20 (v2)
**Approved:** 2025-02-21
[Full proposal text inline or link to Drive]
## Agreement
**Signed:** 2025-02-22
**Invoice:** Sent 2025-02-22, $7.5K upfront
**Payment Received:** 2025-02-23
## Project Notes
[Ongoing context as project executes]
- 2025-02-24: Kick-off call, confirmed user research starts Monday
- 2025-02-27: Completed 8 user interviews, key insight: users confused by step 3
[...]
Every interaction, every decision, every artifact reference—centralized.
When I need to remember “what did the client say about budget constraints?”—it’s in one place. When a team member needs to understand client context—one note.
The Swimlane Diagram
To make the process explicit and visual, I created a swimlane diagram showing the full onboarding lifecycle with clear handoffs:
┌─────────────────────────────────────────────────────────────┐
│ LEAD INTAKE │
│ ↓ Create client note in Obsidian │
│ ↓ Log source, initial details │
│ ↓ Assess fit │
└──────────────────────┬──────────────────────────────────────┘
↓ Fit confirmed
┌─────────────────────────────────────────────────────────────┐
│ DISCOVERY │
│ ↓ Schedule Google Meet │
│ ↓ Conduct discovery call │
│ ↓ Document: problem, constraints, goals │
│ ↓ Internal fit assessment │
└──────────────────────┬──────────────────────────────────────┘
↓ Fit confirmed
┌─────────────────────────────────────────────────────────────┐
│ PROPOSAL │
│ ↓ Draft in Obsidian (proposal template) │
│ ↓ Internal review │
│ ↓ Export to PDF/Doc, share via Drive │
│ ↓ Log: sent date, version │
│ ↓ [Revision loop if needed] │
└──────────────────────┬──────────────────────────────────────┘
↓ Client approves
┌─────────────────────────────────────────────────────────────┐
│ AGREEMENT & PAYMENT │
│ ↓ Prepare contract, share via Drive │
│ ↓ Send invoice │
│ ↓ Log: signed date, payment received │
└──────────────────────┬──────────────────────────────────────┘
↓ Payment confirmed
┌─────────────────────────────────────────────────────────────┐
│ PROJECT EXECUTION │
│ ↓ Create ClickUp project │
│ ↓ Kick-off call (Google Meet) │
│ ↓ Ongoing: tasks in ClickUp, context in Obsidian │
└─────────────────────────────────────────────────────────────┘
This diagram lives in the Obsidian vault as documentation. New team members can see the entire flow at a glance.
Templates & Checklists
To make the system repeatable, I created templates:
Client Note Template
Every new client starts with this structure:
# [Client Name]
## Metadata
- Source:
- Industry:
- Initial Contact:
- Status:
- ClickUp Project:
## Background
[What they do, context]
## Discovery Call
**Date:**
**Attendees:**
**Problem:**
**Constraints:**
**Goals:**
## Proposal
**Sent:**
**Status:**
[Proposal content or link]
## Agreement
**Signed:**
**Invoice:**
**Payment:**
## Project Notes
[Ongoing context]
Discovery Call Checklist
Used during every discovery call to ensure consistency:
- Understand the problem (not the solution they think they want)
- Identify constraints (budget, timeline, technical, organizational)
- Define success criteria (what does “done” look like?)
- Assess internal fit (do we have capacity? right expertise?)
- Document next steps explicitly
Proposal Template
Standard structure:
- Problem Definition (in their words)
- Proposed Approach (how we’ll solve it)
- Scope (what’s included, what’s not)
- Timeline (phases, milestones)
- Pricing (transparent breakdown)
- Terms (payment, revisions, ownership)
Current Metrics (February 2025)
Cost:
- Monthly: $0
- Tools used: 6 (all free tiers)
Onboarding efficiency:
- Average lead-to-agreement time: 7-10 days
- Proposal revision rate: 1.2 revisions per client (low, because discovery is thorough)
- Context retention: 100% (everything in Obsidian)
Scalability:
- Time to onboard new team member to system: under 1 hour (read process doc, see example client note)
- Number of clients managed simultaneously: tested up to 8, no friction
Client satisfaction:
- Post-onboarding feedback: consistently positive on clarity and professionalism
- No client has ever complained about lack of fancy tooling
What I’d Change
Automate proposal generation from Obsidian. Currently I manually export proposals from Obsidian to PDF. Could script this with Pandoc or a simple Node script to generate PDFs from markdown templates automatically.
Better invoice tracking. Right now invoices are logged manually in Obsidian. Could integrate with Stripe or Wave (both free) and auto-sync invoice status to Obsidian notes.
Client-facing status dashboard. Some clients ask “where are we in the process?” Could build a simple read-only dashboard that pulls from Obsidian and shows current stage. But this might be over-engineering—WhatsApp updates work fine.
Template version control. Templates live in Obsidian but aren’t version-controlled separately. Should move them to a Git repo so improvements are tracked over time.
Why This System Works
1. Process-First, Tools-Second
The system was designed from the workflow, not from the tools. I didn’t start by asking “what CRM should we use?” I started by mapping the actual steps, handoffs, and artifacts. Then I asked: “What’s the simplest tool for each responsibility?”
This inverts the normal approach. Most teams buy tools and then try to force their process into the tool’s assumptions. That’s backwards.
2. Documentation as First-Class Citizen
Obsidian isn’t a task manager. It’s not trying to be. It’s a documentation and context preservation tool. That’s what onboarding needs most—not task tracking, but context retention.
When a client says something important three weeks ago, I can find it in 5 seconds via search. When someone asks “why did we scope it this way?”—the reasoning is documented.
3. Clear Separation of Concerns
Each tool has one job:
- Obsidian = context
- Drive = file sharing
- Meet = calls
- WhatsApp = client comms
- Discord = team comms
- ClickUp = task execution
No overlaps. No confusion about where something lives. This reduces cognitive overhead.
4. Zero Vendor Lock-In
If Obsidian disappeared tomorrow (unlikely, it’s local-first), I still have markdown files. If Google Drive shut down, I’d switch to Dropbox in 10 minutes. If ClickUp changed pricing, I’d move to Trello or Notion.
No part of this system depends on a specific vendor. That’s intentional.
5. Constraint-Driven Design
The constraint of “zero cost” forced clarity. I couldn’t hide behind expensive features. I had to think: what’s actually essential? What’s the minimal viable system that works?
Turns out, you don’t need much. Clear process + simple tools = sufficient.
When This System Breaks
This works because I’m operating at a specific scale and mode:
- Solo or small team (1-3 people)
- Service business (not product)
- Low client volume (5-10 active clients at a time, not 100)
- Technical comfort (comfortable with markdown, Obsidian, scripting)
This system would NOT work if:
- You need CRM features (sales pipeline automation, lead scoring, email sequences)
- You have a large team (10+ people need centralized collaboration, not local markdown files)
- You’re managing 50+ clients simultaneously (Obsidian search works, but a database would be better)
- You need advanced reporting (revenue forecasting, pipeline analytics—you’d want a proper CRM)
At that point, you’d graduate to paid tools. But you’d still keep the core principle: process-first, tools-second.
The Deeper Point
Most teams confuse “we need better onboarding” with “we need better onboarding software.”
These are not the same problem.
Software amplifies process. If your process is unclear, software makes the confusion faster. If your process is clear, software makes it more efficient.
The insight: Start with process. Make it explicit. Document it. Then—and only then—ask what tooling supports it.
This system proves you can design robust, professional client onboarding without spending money. Not because free tools are magic, but because clear thinking scales better than expensive software.
Current status: Active system, used for all client onboarding
Cost: $0/month
Time to implement: 2 days (process design + template creation)
ROI: Infinite (no cost, clear value)
This is how I think about systems: process first, tools last, clarity always.