I run a workflow automation agency, and I'm looking to partner with sales-focused people, consultants, or agency owners who can help bring in new clients. If you're skilled at lead generation, sales, or managing client relationships, we could be a great fit. I'll handle everything technical: from strategy and automation design to implementation. Together, we can sell solutions ranging from $500 one-time projects to $15,000+/month retainers, depending on the client's needs. If you're interested, send me a DM, and let's schedule a quick Zoom call to see if we're a good fit

I answered this in comments for someone else and thought it was worth turning into a post since others may not be coming into this with much sales experience. Don't list your capabilities If you're walking into a sales meeting listing your capabilities, you've already lost the room. Here's how I'd structure the opening meeting for discovery of their need: Two discovery questions that route the whole conversation: 1. Where do you think your team loses the most time or money to manual work? Is it [area 1], [area 2], or [area 3] of your business? Which one's the biggest headache? Swap in the 2-3 areas that matter most for their business and the title of the person you're speaking to. Their answer tells you exactly which capabilities matter and which ones to never mention. 2. Across your entire business, if you could eliminate one manual process tomorrow, which one would save you the most? Any rough sense of what that costs you in hours or dollars? If they can quantify it, you have your ROI case. If they can't, that's your audit deliverable. Bonus: a couple follow-ups that earn trust fast: - "Have you looked at any automation before? What happened?" reads whether they've been burned by vendors. - "If we found something that worked in one part of your business, what does it look like to roll it out to the rest? Is that your call?" tells you whether this person can pull the trigger or if you need someone else in the room. On sharing capabilities upfront: don't list them. They don't know what voice agents or automation tools actually are. If you list capabilities they'll nod politely and forget all of it. Once you've heard their bottleneck, tell a story instead. "A company we worked with had a similar problem, their team was spending X hours a week on this. We built something that cut it to Y." Let them see the outcome in a situation that sounds like theirs. The specifics come on call two once they're bought in on the problem being solvable. Hope this helps someone close their next sale.

First step is the thinking/building/product split I mentioned inside a single project here https://www.skool.com/ai-automation-society/how-i-structure-projects-so-my-obsidian-second-brain-works-efficiently?p=18e6d9d9 But once you're managing a business or multiple clients, you need three more layers on top of it: 1) Canonical vault — this is your business's protocols and SOPs. Not project-specific, this is the stuff that's true across every project: your frameworks, your qualification criteria, your playbooks. This is what compounds. Every project's thinking folder feeds into this when something is reusable, not just filed to Obsidian and forgotten. 2) Client vault — one vault, individual folders per client, each with its own knowledge base. Client history, decisions made, what's worked and what hasn't for them specifically. This is different from the canonical vault because it's not reusable across clients, it's specific context that needs to persist for that one relationship even as projects with them come and go. So the full picture is: project-level thinking/building/product folders feed into either the canonical vault (if it's a reusable pattern) or the client vault (if it's client-specific context) once a project checkpoints. 3)Your personal Obsidian second brain sits above both, for the stuff that's neither business protocol nor client-specific, just your own accumulated knowledge. Curious to always learn, how are others here doing it?

I answered this question for a member and felt would be helpful for others as a post. Stop setting up Obsidian before you have anything worth putting in it. The temptation is to set up Obsidian first and figure out what goes in it. I did it the other way and it worked better. Every new project I spin up gets three folders from day one: thinking (research, decisions, context), building (active work, what's in progress, what's blocked), and product (what ships, outputs, deliverables). I can't take credit for this system; I learned it from another creator. That being said, it is this structure that helps Claude always know where to look depending on what I'm doing. The routing is a claude.md at the project root that points to the right folder. Once a project hits checkpoints or wraps, the thinking folder is what migrates to Obsidian. That's your second brain. Not everything you ever touched, just the distilled knowledge worth retrieving later. The building and product folders stay with the project. Where I started: project folder structure, not notes, not tasks, not a blank Obsidian vault. Getting the thinking/building/product separation right inside each project meant I actually had something worth moving to a second brain later. If you start with Obsidian you'll spend weeks organizing empty folders. On integrating Obsidian with Claude to auto-summarize and pull past research: the real unlock isn't the Obsidian integration itself, it's the context handoff system. Past research lives in Google Docs. Those get converted to markdown files and loaded into Claude Projects as context. Claude works from those during active projects. Then at checkpoints, the distilled insights move to the Obsidian vault. The chain is Google Docs (raw research) → md files in Claude Projects (active context) → Obsidian vault (long-term second brain). That handoff is the integration. What I wish someone told me: separate every project folder into thinking, building, and product from the start. I wasted time early on with flat project folders where research sat next to active work sat next to finished deliverables, and Claude couldn't tell what was current vs. done. The three-folder split fixed that overnight.

Hey everyone, I've landed an in-person meeting with the operations manager of a leading end-to-end energy solutions provider. They run 1,000+ gas stations, and almost everything is still manual — minimal automation, and zero AI so far. Big opportunity, and I want to walk in asking the right things rather than pitching. Two things I'd love the community's take on: 1. What are one or two sharp discovery questions you'd ask to get them talking about their real bottlenecks? 2. Would you share your capabilities up front (voice agents, Make.com automations, custom app development, an AI OS for executives, AI training for staff) — or hold back and let their problems lead the conversation? Leaning toward listening first, but curious how you all handle that opening meeting. Appreciate any wisdom