Automated Client Onboarding

Every freelancer and agency operator knows the feeling. A new client signs on, you're excited about the work, and then you spend the next week chasing down logins, tracking missing assets, and waiting for a signed agreement that should have arrived days ago. The creative work sits untouched while the administrative machinery grinds forward one email at a time.

I built an AI agent to handle all of it.

The problem with client intake

Client onboarding looks simple on paper. Collect contact info. Send a service agreement. Get platform access. Start the work. In practice, it's one of the most error-prone processes in a consulting business. Every missed step creates a downstream problem.

Forget to collect a social media login? The designer can't pull brand assets. Skip the service agreement? You're doing work without a contract. Miss a credential? The developer stalls mid-build waiting for access that nobody remembered to request.

The real cost isn't the delay itself. It's the context switching. You're halfway into creative strategy when you realize you never got the analytics password. Now you're writing a follow-up email instead of writing copy. Multiply that by five clients and you've lost a day to administrative friction.

What the agent does

The onboarding agent is a Claude Code skill invoked with a single command: /onboard. It manages the entire client intake lifecycle through four sequential phases, each with its own completion criteria. Nothing advances until the current phase is finished.

This isn't a chatbot that asks questions. It's a workflow engine that creates structured data, generates documents, enforces security protocols, and gates readiness before any creative work begins.

  INTAKE          AGREEMENT        ACCESS           GATE
  ──────          ─────────        ──────           ────
  Collect         Generate         Track            Verify
  contact info    service          platform         contract
  + create        agreement        logins +         signed +
  client dir      from template    store creds      access
                  + draft via      securely         confirmed
                  email                              │
    │                │                │              │
    ▼                ▼                ▼              ▼
  contact.md     agreement.md     assets-          HANDOFF
  assets-        (human           access.md        to design,
  access.md      approval                          copy, dev
                 required)                          agents

Phase 1: Intake

When the agent starts, it collects the basics: client name, primary contact, business type, project scope, and any special requirements. Nothing fancy. But instead of dumping this into a note or a spreadsheet, the agent creates a structured client directory.

Two files get created immediately: contact.md with all client details in a consistent format, and assets-access.md with a tracking matrix for every platform credential the project will need. The directory structure is standardized across every client. Same file names. Same sections. Same format.

This matters because the client directory isn't just for the onboarding agent. It's shared infrastructure. Every other agent in the system reads from it.

Phase 2: Service agreement

The agent generates a service agreement from a template, populated with the client's specific details: scope of work, deliverables, timeline, and terms. The agreement is drafted and sent via email for review.

There's a hard gate here. The agent drafts the agreement, but it doesn't send it autonomously. A human reviews and approves every agreement before it goes to the client. This is intentional. Service agreements are legal documents. They need human judgment on pricing, scope boundaries, and terms that might need adjustment for a particular engagement.

The agent handles the mechanical work — pulling templates, filling in details, formatting, drafting the delivery email. The human handles the judgment call.

Phase 3: Access and credentials

This is where most manual onboarding falls apart. The agent tracks every platform login needed for the project: CMS access, analytics, social accounts, email marketing platforms, hosting dashboards, domain registrars. Each one gets a status: requested, received, verified, or blocked.

When credentials come in, they're stored in OS-level encryption — the macOS Keychain. Never in a text file. Never in a document. Never in a chat thread. The naming convention is strict: {client}_{service}_{type}. Every credential follows the same pattern, making them easy to retrieve and impossible to confuse across clients.

Plaintext credential storage is prohibited. No exceptions. Not "just for now." Not "just for this one client." The security protocol is absolute because security doesn't work when it's optional.

The agent also verifies that credentials actually work. Getting a password is one thing. Confirming you can log in and access the right account level is another. The access matrix tracks both.

Phase 4: The readiness gate

This is the mechanism that makes the whole system work. Nothing proceeds to creative work until two conditions are met: the service agreement is signed, and minimum required access is confirmed.

No exceptions. The designer doesn't start on brand guidelines until the contract is signed. The developer doesn't begin building until platform access is verified. The copywriter doesn't draft content until the project scope is locked.

This sounds rigid. It is. And that's the point.

Without readiness gates, creative work starts before access is confirmed. The developer builds a site, then discovers the client's hosting account requires a two-factor code that only the client can provide — and the client is on vacation. The designer creates brand assets based on a verbal brief, then the signed agreement comes back with a different scope. Rework. Delays. Frustration on both sides.

The gate eliminates an entire class of problems by refusing to let downstream work begin until the foundation is solid.

The shared data model

The client directory that onboarding creates becomes the single source of truth for every other agent in the system. The designer reads brand guidelines and creative direction from it. The copywriter reads brand voice profiles. The developer reads technical specifications and access credentials (via the Keychain).

When onboarding adds a new file to the client directory, every other agent can immediately use it. When the designer finishes a brand guidelines document, the copywriter can reference it without anyone forwarding anything. The data flows because the structure is shared.

• Onboarding creates: contact info, access tracking, service agreements
• Designer adds: brand guidelines, asset libraries, design specifications
• Copywriter adds: brand voice profiles, content deliverables
• Developer reads: technical specs, platform access, deployment requirements

No handoff meetings. No "can you send me that file." The data is already where it needs to be.

Why gates matter more than speed

The instinct in most service businesses is to start work as fast as possible. The client just signed. They're excited. You're excited. The temptation is to skip the process and jump straight into the creative work.

Every time I've done that, I've regretted it. Work starts without a contract, and the scope shifts three times before anyone notices. Access gets "collected later," and the project stalls at 80% completion waiting for a password. The brand voice profile never gets written because nobody paused to do the intake properly, so the copywriter guesses — and guesses wrong.

Gates are the opposite of fast. They're deliberate. They force you to finish one thing before starting the next. And in practice, they make everything downstream faster because the foundation is right.

What I learned building this

The hardest part wasn't the technical implementation. It was committing to the workflow. Every gate is a moment where you have to tell a new client — or yourself — "not yet." That takes discipline.

The second lesson: credential security has to be a first principle, not an afterthought. If you design the system to store credentials securely from the start, it's easy. If you try to retrofit it later, you'll find plaintext passwords scattered across five different tools and twelve conversation threads.

The third: shared data models are worth every minute of upfront design. When every agent reads from the same directory with the same file structure, coordination becomes automatic. When they don't, you spend your time being a human router — copying data between systems that should have been connected from the beginning.

The onboarding agent isn't the most exciting thing I've built. But it might be the most important. It turns client intake from a source of friction into a foundation that everything else builds on. The creative work gets better because the setup was right. The downstream agents move faster because the data is already there. And nothing ships until it's ready.

That's how the work gets done.