I manage 16 clients at an SEO consultancy firm. Every client has their own goals, their own tech stack, their own pace. Some I talk to every other week, some once a month, some barely at all. And all of them expect me to remember exactly where we left off.
For a while, I did. Mostly. I'm a systems person by nature, I've always been drawn to building structure around the things I do. I had Todoist for tasks, Google Calendar for meetings, Fireflies for transcripts, Google Drive for docs. Each system worked fine on its own.
The problem was never the individual tools. The problem was that none of them talked to each other.
The problem
Here's what a typical week looks like:
I'd have 6-8 client meetings. Fireflies would record all of them. I'd take mental notes during the call, maybe jot something down. Afterwards, the transcript would sit in Fireflies. Technically available, practically untouched. The action items I promised would land in Todoist, sometimes. And if they were to land, I needed to add them manually. The strategic decisions we made would live in my head or I needed to annotate them somewhere.
Then Friday would come around, and I'd need to write CRM updates for every client. That meant opening Todoist to see what I'd done, checking my calendar to remember who I'd met, trying to recall what we actually discussed, and occasionally diving into a Fireflies transcript to confirm something. For 16 clients. Every week.
It was detective work. I'd spend hours reconstructing a week I'd already lived through for it to be documented both for myself and the rest of the team.
And the prep situation wasn't much better. I'd have a client meeting at 10, and at 9:45 I'd be scrambling. What did we talk about last time? What's their current priority? Did I deliver that thing I said I would?
The data existed. Somewhere. Scattered across five different platforms, none of which gave me the full picture of any single client relationship.
I don't think this is a unique problem. Anyone running multiple client relationships simultaneously probably recognises it. The information is there, it's just not together.
What I built
The short version: I built a local knowledge base in Obsidian with a standardized folder per client, wrote rules and SOPs that Claude follows when working with those files, and layered scheduled automations on top that handle meeting processing, task distribution, CRM documentation and a few other things throughout the week. I do almost all of my work through Claude Code. I rarely open the vault itself anymore.
Let me walk through the parts.
The knowledge base
The foundation is embarrassingly simple. It's a folder structure. Each client gets a folder with four files:
- profile.md: who they are, who my contact is, what their tech setup looks like, what services we provide.
- activity-log.md: a running log of everything I do for and with this client, newest first.
- strategy.md: current goals, KPIs, what we're working towards, and what's on the backlog.
- meetings/: individual meeting notes, one file per meeting.
That's it. Sixteen copies of this structure, one per client.
The part that makes it work, and this took me a while to figure out, is that the activity log has to be rich. Not "worked on client X's blog post" but "created a blog post targeting [keyword] because organic traffic for this topic cluster dropped 12% last quarter. Post is published and indexed, next step is monitoring ranking movement over the next 2-3 weeks and building internal links from the existing service page."
That distinction matters enormously, and I'll come back to it.
Obsidian as the hub
I chose Obsidian for a boring reason: it's just a folder of markdown files. There's no database, no proprietary format, no API layer between me and my data. Claude can read and write to these files directly. I can read and write the content easily on all my devices. That turned out to be the most important technical decision in the entire project.
I made several turns with Claude on what the foundation should be, and started in several directions before landing in Obsidian. I'm sure this system would work just as well with Notion or any other similar tool, Obsidian just fit me better.
Obsidian gives me a nice way to browse and search the vault, but the real value is that the files are just files. SOPs live in the vault. Templates live in the vault. The system documents itself inside the same structure it operates on.
I also store overview documents: my role, the tools I use, how the team works so that when Claude needs context, it reads the same files I'd read.
The automations
This is where it gets interesting. I've built eleven scheduled automations that run throughout the week. They do the boring work I used to do manually.
Monday morning, weekly scrum and task distribution. Pulls what I completed last week, looks at this week's calendar, and distributes open tasks across the week. Clients with meetings coming up get their prep work scheduled before the call, not the morning of.
Monday morning, CRM sync. Pulls client notes, service grades, and contract details from the company CRM database into the knowledge base. Client profiles and strategies stay current without me copying data between systems.
Monday morning, meeting prep tasks. Scans this week's calendar and creates preparation and follow-up tasks in Todoist for upcoming client meetings.
Every weekday morning, daily meeting follow-up. This is probably the automation that changed the most about how I work. It checks yesterday's calendar for external meetings, grabs the Fireflies transcript, and does the processing I never had time for: creates a structured meeting note in the vault, writes a rich activity log entry, and drafts a follow-up email. The meeting context that used to evaporate overnight now gets captured and filed before I've had my second coffee.
Wednesday, safety net. A mid-week scan that catches the things that would otherwise slip. Overdue tasks. Action items from meetings that never became tasks. Clients I haven't interacted with in a while. It runs eight different checks. Think of it as a system that taps me on the shoulder and says "hey, you forgot about this."
Every two weeks, client review prep. Before recurring client review meetings, it compiles a brief of recent work, open items, and strategic context. Proposes tasks for me to approve rather than creating them autonomously. There's a difference between automation and delegation, and this one sits firmly on the automation side.
Friday morning, review nudge. Before the main weekly review, it flags clients where I have task activity but thin context in the KB. "You worked on this client's site this week but there's no meeting note. Want to add some context before the review?"
Friday afternoon, weekly review. The big one. This is the automation that solved the original problem. It pulls together completed tasks, activity logs, meeting notes, and calendar data, and generates CRM-ready comments. Two checkpoints where I review and approve before anything gets posted. What used to take half a day now takes about thirty minutes of reviewing what it's compiled.
Friday afternoon, systems review. This one's a bit meta. The system reviews its own performance. It looks at what worked, what failed, and proposes improvements. It also extracts learnings from the week's sessions and checks for new skills and automations worth implementing. The system improves itself, basically.
Monthly, performance pull. On the first of each month, it pulls SEO performance reports into each client's performance file. Gives the weekly review actual data to reference instead of vague impressions.
On top of the scheduled tasks, I've built reusable skills. Packaged workflows I can trigger whenever I need them. CMS page formatting that converts markdown to whatever format a client's site uses. SEO blog writing that follows a defined process. On-demand Fireflies processing for when I need to handle meetings outside the daily automation.
The auto-behaviors
The scheduled automations run at set times. But the system also has reactive behaviors that kick in during normal work, defined in a single rules file (CLAUDE.md) that Claude reads at the start of every session. These are what make it feel less like a tool and more like something that understands the system.
Auto-Read. When I mention a client by name, Claude silently loads their profile, activity log, and current strategy. I don't have to say "read the file for Client X." It just knows the context by the time I ask a question.
Auto-Log. After I do meaningful work for a client, Claude writes the activity log entry automatically. Not "updated blog post" but a rich entry with what was done, why, and what's next. These entries feed directly into the Friday CRM review, so their quality matters.
Auto-Update. When a strategic decision comes up in conversation, like a new goal, a changed KPI, or a shift in priorities, Claude updates the client's strategy file. I don't have to remember to do it separately.
Auto-Retrieve. Before starting non-trivial work, Claude silently checks if there are documented solutions or session learnings from previous work that might be relevant. If I solved a similar problem three weeks ago, it surfaces that context instead of starting from scratch.
Auto-Compound. After solving a hard problem, Claude offers to document it as a reusable solution. Investigation steps, root cause, fix, prevention. These feed back into Auto-Retrieve for future sessions.
The net effect is that I don't manage the system. I work, and the system manages itself around my work. The context loading, the logging, the knowledge accumulation: it all happens without me thinking about it.
The guardrails
The auto-behaviors are nice, but they'd be useless without clear rules for how they should behave. A few design decisions that turned out to matter a lot:
Rich logs feed everything downstream. This is the single most important principle. The weekly review generates CRM comments from activity logs. If the logs say "did some work," the CRM comment says "did some work." If the logs say what happened, why it mattered, and what's next, the CRM comment is actually useful. The whole system's quality is determined by the quality of what goes in.
Fallback protocols for everything. Every automation that depends on an external service has a documented "if this fails" path. Browser automation can't reach Fireflies? Ask me for a manual paste, or create a stub with a reminder to process it later. No single point of failure kills the workflow.
Human checkpoints at decision points. The automations handle the grunt work. I make the judgment calls. The weekly review stops twice: once for me to review identified gaps, once for me to approve the comments before they go anywhere. I'm not comfortable fully automating decisions that affect client relationships.
The system documents itself. SOPs, templates, and rules all live in the vault. Claude reads them before acting. When something changes, I update one file and the behavior changes everywhere.
Memory across sessions. Claude Code has a persistent memory system where corrections, preferences, and references carry across conversations. I told it once that activity logs need to be rich. I told it once that Swedish text must use proper characters. I told it that the Monday workflow has three manual phases. It hasn't forgotten any of it. This is what gives continuity across sessions without me repeating myself.
Claude Code as the interface
This part is important and easy to miss when I describe the system: I almost never interact with the vault directly. I don't open Obsidian and browse files. I don't write activity log entries by hand. I don't copy-paste meeting transcripts into templates.
I work in Claude Code. That's it.
When I finish a client session, I tell Claude what I did and it writes the activity log entry. When I need to prep for a meeting, I ask Claude and it reads the relevant files and gives me a summary. When I want to know what's been going on with a client, I ask. Claude reads the profile, the activity log, the strategy, the recent meeting notes, and comes back with context. The vault is the data layer. Claude is the intelligence layer. I'm the one asking questions and making decisions.
The scheduled automations run inside Claude Code too. They're triggered on a schedule, Claude Code spins up, reads the vault, checks Todoist, checks Calendar, does its thing, writes back to the vault. I get a notification when it's done.
The skills work the same way. I say "format this page for Flatsome" or "write a blog post for this client" and Claude has the context it needs because the vault is right there.
This matters because it means the barrier to using the system is basically zero. I don't have to learn a new interface or maintain a dashboard. I just talk to Claude the way I would talk to a colleague. "What's the status on this client?" "Process yesterday's meetings." "Write the CRM updates."
One more thing worth mentioning: I built this on Claude Code and Anthropic's stack, but the concept isn't locked to it. OpenAI's Codex, or any coding agent that can read and write local files, could run the same setup. The vault is plain markdown. The SOPs are plain text. The scheduled tasks are prompts. There's no proprietary dependency beyond the AI model itself.
What actually changed
CRM updates went from a half-day reconstruction exercise to thirty minutes of review. Meeting prep happens before I think about it. I show up to calls actually knowing what happened last time.
The thing I didn't expect: the system made me a better consultant. Not because the automations are clever, but because having a canonical record of every client relationship means I never lose context. A client mentions something from three months ago, and I can speak to it immediately. That builds trust in ways I can't quantify.
What's still rough
I want to be honest about this because building systems is always messier than the blog post about it makes it sound.
The whole thing runs on my machine. If my laptop dies, the scheduled tasks need to be recreated. The vault is plain markdown so it could be version controlled easily, but the automation layer, the scheduled task prompts and skill definitions, lives in Claude Code's config. I've documented all the prompts in an SOP so they can be rebuilt, but it's not one-click portable yet.
The biggest limitation: the system is only as good as what goes into it. If I have a quick call and don't process it, or if the automation misses a transcript, there's a gap. The safety net catches some of these, but not all.
Some parts are still scaffolding, not production. I built the structure for things I haven't fully implemented yet. That's fine, but I want to be upfront about the fact that this is a living system, not a finished product.
Where this goes
A few things I'm thinking about:
Email integration. Right now, email threads are the one data source that doesn't flow into the KB automatically. Auto-surfacing unanswered client emails and pulling relevant threads into the system would close a big gap.
Cross-client pattern detection. The system is great at per-client context, but it doesn't yet spot patterns across the portfolio. "Three of your clients have overdue technical tasks" or "your engagement with these two clients has dropped". That kind of insight.
Automated reporting. Monthly client reports that pull from activity logs and analytics data instead of being assembled manually. The performance data already flows in. The step from data to formatted report is the part I haven't built yet.
What I'd tell you if you're thinking about building this
Start with the activity log. Seriously, just the activity log. One file per client, dated entries, written with enough context that you'd understand what happened six months from now. You don't need automations for that. You don't even need Obsidian. A folder of text files works.
Build iteratively. I didn't design this system on paper and then build it. I started by solving one problem and each solution revealed the next thing that needed fixing. The meeting processing came second. The systems review is brand new.
The automations are nice, but the KB structure is what actually matters. Even without Claude, even without any AI, having one canonical place per client with a predictable file structure would have been a meaningful improvement over what I had before.
Don't over-engineer the templates. Mine are simple. That's the point. Complex templates create friction, and friction means you won't use them.
The hardest part isn't building the system. The hardest part is the discipline to write rich entries instead of "did some work for the client today." That discipline is what separates a useful knowledge base from a filing cabinet nobody opens.
And maybe the most important thing: the system should serve you, not the other way around. There were a few points during the build where I found myself doing work for the system. Formatting things just right, filling in fields I'd never read again. Every time I caught myself doing that, I simplified. The moment your operations system becomes a chore, it's failed.
This is how you do it
I've published a generic version of the system as a public template: github.com/casalm26/client-kb.
It includes the CLAUDE.md with all the auto-behaviors, the folder structure, file templates, SOPs for meeting processing and weekly reviews, and a setup wizard that runs the first time you open the project in Claude Code. The wizard asks your name, what you do, and what tools you use, then scaffolds the vault around your answers.
To get started:
- Clone the repo (or use it as a GitHub template)
- Open the folder in Obsidian
- Open the same folder in Claude Code
- Say anything. The setup wizard takes it from there.
It's not locked to SEO or consulting. Anyone managing ongoing client or project relationships, freelancers, developers, designers, project managers, can use the same structure. The specifics of what goes in the files will differ, but the pattern of structured context feeding into automated workflows transfers directly.
The only hard requirement is Claude Code. Obsidian is free. Everything else, task managers, calendars, meeting recorders, is optional and gets connected during setup if you have it.