Module 6: Tools and SOPs

Clients do not pay for tool loyalty; they pay for work that moves between tools without friction. This module maps the stack you will meet in the wild, gives you a two-hour method for learning any new one, and ends with the habit that turns tool fluency into leverage: writing the procedures down.

The stack by category: fluency beats fandom

Strip the brand names away and every client's stack is the same seven categories. Project boards (Trello, Asana, ClickUp) hold the work. Docs and files (Google Workspace, Notion, Dropbox) hold the material. Communication (Slack, email) carries the conversation. Schedulers queue social posts. Email platforms (Mailchimp, Kit, Flodesk) build and send campaigns. Design basics (Canva) cover graphics. The CRM (HubSpot and its rivals) holds the customer truth from Module 5. You will rarely meet all seven at one client — but you will meet some version of each category at every client.

The transferable skill is recognizing that categories behave alike. Every board is columns, cards, owners, and due dates. Every email platform is lists, segments, campaigns, and reports. Learn the category once and a new brand becomes a two-hour problem (next lesson) instead of a reason to panic. The reverse is also true: deep loyalty to one brand is a liability. The client's stack wins, always — you adapt to their tools, you do not campaign to replace them with yours.

Whatever the tool, the same five moves cover 90% of your work: create, organize (folders, tags, boards), share with the right permissions, find things again (search and filters), and undo or export when something goes wrong. Permissions deserve their own sentence: work inside the client's workspace under an invited seat, and never build client assets inside an account only you control. Keep a running tool log as you go — tool, what you used it for, how comfortable you are. It feeds your services one-pager in Module 8 and your answers every time a prospect asks, “have you used our system before?”

A new client runs everything on a project board you have never opened. Your tool log is deep in a rival board. What's the right response?

Learning a new tool in two hours

New-tool panic usually produces the same mistake: five days of tutorial videos and nothing to show for them. Replace it with a fixed two-hour method. First 20 minutes — orientation: the vendor's own help docs and one overview tour; you are mapping the territory, learning where the lists, settings, and reports live. Next 60 minutes — one real task, end to end: take an actual deliverable from the client's work and produce it in a draft, duplicate, or test area, so your experiments never touch live material.

Next 20 minutes — write your notes: the exact clicks for the tasks you will repeat, in your own words, saved where you can find them. Final 20 minutes — edge cases: how permissions work, how to undo a mistake, whether the mobile app matters for this client. Two hours, and you hold a working map, a finished test deliverable, and notes that become next month's SOP.

Two pitfalls to refuse. The first is bluffing: clients expect a VA to learn tools — it is in the job description — but a VA caught pretending to know, after sending a campaign to the wrong list, is done. “New to your platform; I ran a test build today and here's my one question” builds more trust than false confidence ever will. The second is perfectionism: you need the five core moves from the last lesson, not the settings page's third tab. Depth comes from weekly use. Your two hours buy working competence, honestly labeled — which is exactly what the client is paying for.

On Friday a client tells you that starting Monday you'll build their weekly campaign in an email platform you've never used. What does your two-hour session produce first?

SOPs: document everything you touch twice

An SOP — a standard operating procedure — is a step-by-step document for one recurring task: its purpose, the tools and access it needs, the steps in order with exact menu names or a screenshot, what “done” looks like, and the known failure with its fix. It reads boring. It is the single most valuable habit in this course, because an SOP converts your memory into the client's infrastructure.

Count what that buys. Coverage: when you are sick or on vacation, someone else — or future-you at 7 a.m. — can run the task from the document, so the client's business never depends on your presence. Consistency: the pre-send checklist in Module 4 is an SOP; it catches the same errors whether you slept well or not. Your raise case: “I have documented our twelve recurring processes” is a concrete, countable asset in a rate conversation, in a way “I work hard” never is. And when an engagement ends, leaving clean SOPs behind is the goodbye that generates referrals.

Write them as you work, not after. First time you do a task, just do it. Second time, draft the SOP while you work — ten extra minutes. Third time, follow your own document and fix every place it misleads you. Store SOPs in the client's drive or docs, where they can see the library grow, and date each one: processes change, and a stale SOP for anything involving sending or publishing is worse than none, because people trust it. Start yours now.

Your turn: Write your first SOP for one recurring task from this course so far — the pre-send email check, a website link check, or a weekly report pull. Include: the purpose in one line, the tools/access needed, the steps in order (exact menu names where they matter), what “done” looks like, and one failure you've seen or can imagine, with its fix. Date it at the top.

Reviewing your rate, a client asks why they should pay for time you spent “writing documents about the work instead of just doing the work.” What's the honest answer?

What you can now do

Sort any client's stack into the seven tool categories and work across brands, instead of being loyal to one app.
Learn an unfamiliar tool in two hours: orient in the help docs, run one real task end to end, and skip the five days of tutorial videos.
Write an SOP for anything you touch twice — purpose, tools and access, steps in order, what "done" looks like, and the known failure with its fix.