Lead To Close In HighLevel, Written Down Once And Deployed By Script
If you run a HighLevel agency you will know this feeling. You set up a sub-account, it works, the client is happy. Three months later you set up the next one and it is nearly the same but not quite, because you were doing it from memory and you improved two things on the way.
Do that twenty times and you have twenty snowflakes. Every support question starts with "which version of the setup does this one have".
So we wrote the setup down properly and then made a script build the parts a script can build.
The blueprint
Two pipelines, because lead acquisition and existing-client growth are genuinely different motions and cramming them into one board makes both worse.
Aiva Outreach carries a prospect from first contact to signed. Client Success and Upsell carries an existing client from onboarded through to the next thing they buy.
Underneath that, the boring but load-bearing stuff: the custom fields that every workflow reads, the tag vocabulary, and the workflow specs. All of it specified in one document rather than living in whoever built it last.
The tag vocabulary matters more than people expect. Tags are how the automations decide what to do, and if two sub-accounts spell the same concept differently then nothing is portable. Pick the words once.
The script
setup.mjs builds the API-creatable parts from a config file: custom fields, tags, pipelines.
The important word is idempotent. You can run it against a sub-account that is half set up, and it creates what is missing and leaves what exists alone. That matters because the real world is not clean installs. The real world is a client who already has four pipelines and some tags a previous agency made.
Non-idempotent setup scripts are worse than no setup script, because the first time someone runs one twice you get duplicates and then nobody trusts it again.
What the API will not do for you
Not everything in HighLevel is API-creatable. Workflows in particular still need building in the UI. So the blueprint document carries the workflow specs as specs, numbered and named consistently, and somebody follows them.
That is fine. The value is not full automation, it is that there is now one definition and the manual steps are a short explicit list rather than whatever the last person remembered.
The bit that will catch you
We verified the API was reachable and the script ran, and then hit the thing everyone hits: the Private Integration token needs the right scopes granted, per scope, in the sub-account. A token that authenticates fine will still 401 on a pipeline write if pipelines are not in its scopes.
If you are debugging a HighLevel API call that authenticates and then refuses, go and look at the token's scope list before you look at anything else. It is almost always that.
Why this was worth the day
Onboarding cost is the thing that decides whether a productised service works at volume. At one client a month you can afford to do it by hand. At eight a month you cannot, and you find that out at client five when you are already committed.
Better to have written it down before you need it.