Building Systems That Survive Staff Changes

A consulting practice that depends entirely on one person’s memory, relationships, and habits is fragile. When that person goes on medical leave, takes a vacation, or leaves — everything stops. The goal is to build systems that make your practice resilient, whether you’re solo or managing a team.

What “Systems” Actually Means

This isn’t about buying project management software (though that might help). Systems are the documented, repeatable processes that allow work to continue regardless of who’s doing it.

Client Onboarding Process

A documented sequence: intake form, discovery call agenda, what to collect (org docs, financials, past proposals), how to set up the workspace, when to send the contract. Anyone following this process creates the same consistent starting experience.

Proposal Production Workflow

From RFP review to submission: who does what, in what order, with what tools, by what deadline. Include quality checkpoints and decision criteria for when to escalate issues.

File Organization Standard

Where things go and what they're called. A naming convention, a folder structure, and a rule about where active vs. archived work lives. This sounds minor until someone spends an hour looking for last year's budget template.

Client Communication Templates

Standard emails for common situations: engagement kickoff, information requests, draft delivery, revision turnaround, project completion. Customize the content; keep the structure consistent.

Knowledge Base

Your accumulated know-how: common funder requirements, typical timeline for different proposal types, pricing guidelines, lessons learned from past projects. This is the institutional memory of your practice.

The Bus Test

Here’s a blunt question: if you were unavailable for two weeks starting tomorrow, could someone else keep your active engagements moving? If the answer is no, your systems need work.

This isn’t just a thought experiment for team-based practices. Even solo consultants get sick, have family emergencies, or simply want a vacation. Having documented systems means you can bring in a subcontractor to cover, or at minimum, your clients know what’s happening and when to expect the next deliverable.

Document your systems while you’re doing the work, not after. The best time to write a process document is immediately after you’ve done something for the third time. By then, the pattern is clear and the details are fresh.

Starting Simple

You don’t need a 200-page operations manual. Start with the processes that would cause the most damage if they broke:

Where are the active client files? Anyone should be able to find every active engagement’s current documents in under two minutes.
What’s the status of each engagement? A simple tracking document showing each client, their current proposal, where it stands, and what’s due when.
How do we submit a proposal? The specific steps for uploading to Grants.gov, submitting to a foundation portal, or emailing to a program officer. Include login credentials (stored securely) and formatting requirements.
How do we invoice? The template, the payment terms, the invoicing schedule, and where to track what’s been paid.

In Grantable

Grantable workspaces serve as a natural system of record for each client. Documents, grant pipelines, communication history, and AI context all live in one place per client — making it straightforward for anyone with workspace access to understand the current state of an engagement.

Process Documentation That People Actually Use

The best process documents share a few characteristics:

Short and scannable. Bullet points and numbered steps, not paragraphs. Someone should be able to follow the process by scanning the document, not reading an essay.

Specific about tools and locations. “Upload the proposal” is vague. “Log into Grants.gov using the credentials in 1Password under ‘Federal Submissions,’ navigate to the workspace, and upload the PDF” is actionable.

Updated when things change. A process document that’s two years out of date is worse than no document — it gives people false confidence. Review quarterly, or whenever a process changes.

Accessible without asking someone. If the document lives in a folder that only you can access, it doesn’t survive your absence. Shared drives, project management tools, or a shared workspace — put it somewhere others can find it.

Version Control for Proposals

One system that saves enormous headaches: clear version control for proposal drafts.

A simple convention: ClientName_FunderName_v1-draft.docx, ClientName_FunderName_v2-review.docx, ClientName_FunderName_FINAL.docx. The exact convention matters less than having one that everyone follows.

Never edit a file called “FINAL.” If changes are needed after final review, create a new version. The number of times a submitted proposal turned out to not be the final version is… too high in most practices.

Check your understanding

You're a solo consultant about to take two weeks of vacation. You have three active engagements with work due during that period. What's the minimum system you need in place?

Key Takeaways

Systems are documented, repeatable processes — not software purchases
Apply the 'bus test': could someone keep your engagements moving if you were unavailable for two weeks?
Start with the four essentials: file location, engagement status, submission process, and invoicing
Document processes while doing the work, keep them short and scannable, and update them when things change

Next Lesson

You’ve built systems that work. Now for the big question: do you want to stay solo forever, or build something bigger? The tradeoffs are real — and they’re next.