Key takeaways
- Internal work runs on a project board, client work stays in the CRM, and that line is defended on purpose.
- The test is simple. If the work is attached to a person, it lives on that person's record. If it is attached to a build, it lives on the board.
- Four automations that already created tasks were deliberately left pointing at the CRM rather than moved to the shiny new tool.
- One client gets one project, because the project is the only place the tool can draw a permission line.
- Nobody gets a project until they have paid, because a project created in hope sits in the sidebar forever.
We added a project board this month. Internal builds, content projects, the ops work that never belonged in a CRM. Two people use it, it is self hosted, and it costs nothing per seat.
The interesting part was not setting it up. It was deciding what we refused to put in it.
The line: is this work attached to a person
Every task in this business is one of two shapes, and once you see it you cannot unsee it.
Some work is attached to a build. Ship the landing page. Rebuild the reporting view. Write the September content batch. It has phases, it has a finish line, and it belongs on a board.
Other work is attached to a human being. Call this lead back Thursday. Send the proposal. Follow up on the thing they mentioned. That work has a person's name on it, and its only sane home is that person's record in the CRM.
So when we stood up the board, the honest move was to leave four existing automations exactly where they were. The one that creates a task from a request, the one that reports what is open, the one that turns meeting action items into tasks, and the one that researches new website leads. Every one produces work with a contact attached, and moving them would have taken a follow up off a client's timeline and buried it on a board that client will never appear on.
That was a decision, not an oversight. New tools have gravity, and the pull to migrate everything into the thing you just built is usually wrong.
One client, one project, because of where the fence is
The next call was shape. A board can hold clients as projects, or as one project with a section per client. Sections look tidier, and they were the wrong answer for a reason that has nothing to do with tidiness. This tool has no permission boundary below the project. Roles exist at the workspace level and the project level and nowhere else. So if you ever want a freelancer to see one client's work and not the other seven, project per client is the only shape that can do it.
The general version: decide your structure by where the tool can actually draw a fence, not by which layout reads best when it is empty. Layout you can change. A permission boundary you cannot invent.
A project is permanent furniture
The rule we settled on is that nobody gets a project until money has actually moved. Not a promising call, not a signed intent, an actual payment.
The tempting shortcut is to read the sales pipeline instead, so anyone at a late stage becomes a project. That would have been a disaster here, because we have never marked a single opportunity as won. The stage field is not a lie, it is just not a thing anybody in this business updates, and reading it would have filed hundreds of cold prospects as active clients.
Free work is the one exception. It gets a project so it stays trackable, with the price written in as zero so it never reads as revenue later.
The reason is that a project is permanent furniture. Created in anticipation, it sits in the sidebar forever, indistinguishable from the ones that converted, and six months later you cannot tell your real client list from your hopeful one.
Two things the tool got wrong that we only found by checking
Two findings worth passing on, because both looked fine from the outside.
The first is a security one. Our setup script created every client project as private, sent that through the API, and got a success response back. It was silently ignored, and every project landed readable by anyone in the workspace. Harmless today, because the workspace has one person in it. But the whole reason for project per client was walling contractors off from each other, so believing it worked is exactly how client A's work reaches client B's freelancer.
The second is a reporting one. The board's own progress counters are wrong. On a real project they reported six items done out of forty seven when the true figure was twenty eight. A section that was one hundred percent complete reported one item finished, same as a section barely started. Read those numbers and you conclude a build is stalled when it is most of the way through.
Both have the same shape. The tool answered confidently, the answer was wrong, and the only thing that caught it was counting the underlying records by hand.
What this means if you are hiring a GHL consultant Bay Area side
Most small businesses we talk to have the opposite problem to too many tools. They have one tool doing four jobs badly, or four tools where nobody knows which is the real list.
Three things worth doing this week, none of which need new software:
- Sort your open work by whether it has a person's name on it. Anything with a name belongs wherever you keep that person's history. Everything else can live somewhere else.
- Pick one system per question and say it out loud. Where does a follow up live. Where does a build live. Two plausible homes means neither gets checked.
- Do not create records for work that has not started. Speculative folders and maybe clients never get deleted, and they quietly ruin your ability to see what is real.
The honest lesson is that the value was in the boundary rather than the board. Anyone can install a project tool in an afternoon. Deciding what stays out of it, and then not moving it in when the new thing feels exciting, is the part that keeps a business legible.
If your systems have stopped telling you the truth about what is open, that is most of what we fix. Have a look at optechsol.llc.