Honest one: the gap between building and selling. I am on the dev side, so when a week gets uncomfortable I will happily go refactor something instead of talking to a person, and it feels like progress because there is a commit at the end of it. Nothing gets built by accident. Conversations do. The thing that actually broke it for me was making the day's scoreboard a conversation count instead of a to do list. Not calls booked, not leads, just did I say something to a real human today. Below three and the day did not happen, no matter what got shipped. I mostly work with agencies and service businesses on the automation and backend side. @Remy Thevenot on the procrastinating one, home services is a good spot for this because your list is public and finite. Pick one trade in one city and just write down twenty names by hand tonight. Procrastination for me was almost never fear of the call, it was not knowing exactly who was next when I sat down. A named list of twenty kills that entirely.

The access answers above are right, but the thing that will actually stop you is not access, it is A2P. Before a single review SMS leaves that sub account you need 10DLC registration approved: brand and campaign, filled in with the client's legal business name, EIN, business address, website and sample messages. That takes anywhere from a day to a couple of weeks and it gets rejected for small stuff, like a sample message with no opt out line. A lot of people build the entire workflow, hit send, and then watch every message silently fail with nothing in the UI telling them why. So the actual ask list from your client is shorter than you think: Legal business name, EIN and business address, for A2P. Their Google review short link, which they pull from their Google Business Profile under Ask for reviews. It looks like g.page/r/something. That is the entire Google piece, zero account access. The past customer list, names plus phone and email, and their word that they have permission to contact those people. If you want email coming from their domain, DNS access or a person who has it, so you can add the sending records. That is the only credential shaped item on the list, and it is DNS, not his Gmail password. Second thing that bites people here. Do not import 500 contacts and fire them all on day one. A brand new number pushing a few hundred SMS in an afternoon looks exactly like spam to the carriers, so it gets filtered and the number gets flagged, and you will never see a bounce that explains it. Drip 20 to 30 a day. Slower, and it is the difference between a number that works in month two and one that is dead. One more on old customers specifically: put the time gap in the message instead of pretending it is not there. Something that acknowledges it has been a while reads like a human. A cold review ask about a job from two years ago reads like a bot.

Snapshot drift is the one that cost me the most hours, and what finally fixed it was giving up on the idea of a single master snapshot. Now the base snapshot only holds the stuff no client ever touches. Pipeline stages, custom field names, the calendar shell. Everything client specific gets pushed as separate workflows. Because the base barely changes, a push stops nuking work somebody did last Tuesday. One thing I would bolt onto that stack: a plain changelog per sub account, one line every time anyone pushes anything. Reads like busywork right up until a client says the automation stopped working and you can tell in ten seconds whether that is real or somebody on their team toggled a workflow off. Before that I was reconstructing it from memory and usually guessing wrong.

You already hit the real wall, which is that everything in the workflow builder is contact scoped, so there is nowhere inside GHL for a per setter counter to actually live. I stopped fighting that one a while ago. What I run for a client with six setters: Task Completed fires a webhook out to n8n, which appends a row with the assigned user id, contact id and completion timestamp. A scheduled run at 6pm groups by user and drops the totals in their Slack, and writes the same summary string into a custom value on the location so it shows on a dashboard tile for the client who refuses to leave the platform. Two things that bit me. The webhook hands you the user id and not the name, so pull /users once and keep a map or the report is a wall of uuids. And a fast double click can fire the completion twice, so dedupe on task id before counting. If you would rather skip webhooks, the v2 tasks search endpoint takes a completed date range, so you can poll it once a day and group by assignedTo. Fewer moving parts and you get backfill for free.

The part that usually bites people at this exact stage is not the build, it is that ten clients at once means ten different definitions of a qualified appointment. You sold volume and you will get volume, then a chiropractor tells you half the bookings were tire kickers and your guarantee quietly turns into a refund conversation. So before you hand fulfillment to anyone, I would write the qualification criteria into the offer itself, per niche, so appointment has a definition you can point at when someone disputes it. Then build it once and clone it. One pipeline, one set of follow up automations, one booking flow, per niche instead of a bespoke thing for every client. That is the difference between fulfilling ten at once and drowning in ten. This is the side I build, conversational booking and follow up layers on GHL and WhatsApp, running in production right now. If you want to run one of the ten through as a proof case first like Mouldi said, happy to hop on a call and map what it would actually take.