All Gusto is a HubSpot Solutions Partner. I manage client HubSpot accounts myself, and I now run a large share of that work through a Grok Bot named Herbert: HubSpot how-tos plus client-portal operation, with API and CLI first and the browser when the API is blocked. This post is how that setup actually looks on a real anonymized job, not a feature list.
Marketing and RevOps leaders at small and mid-size B2B companies on HubSpot ask the same question: who is in the portal, and what changed. The short version is that I still own the work. Herbert is how I open the account through three doors, draft the build, and leave live writes gated until a person says activate.
In scope: what this Grok Bot is for Solutions Partners, why MCP plus API plus UI matters, social proof from an official @grok reply on my post, a real anonymized ticket-status notification build, discovery before build, workflows left Off for activate-with-us, and qualitative time savings only. Out of scope: a full portal teardown (that is a HubSpot portal audit), a net-new architecture job, and a promise that any bot can ship live changes without a person. If you want automation that does not fight itself after the build, start with HubSpot automation without babysitting.
Herbert is the Grok Bot I staff for HubSpot how-tos and for operating inside client portals. The installable template is public: Herbert on x.ai (the card may show an older spelling; in prose the bot is Herbert). Reads are free. Draftable assets can be prepared without me clicking every screen. Live writes into a client portal need my yes before they go. That split is the delivery model. A bot that invents a workflow and turns it on without a gate is how you get double-sends and leftover enrollments.
I still do the work. All Gusto is a HubSpot Solutions Partner, est. 2014. Senior only. No juniors. No offshore handoffs. Herbert is how I move through the portal faster once the job is scoped. It is not a second consultant on your call. If the bot cannot open the object, I open it. If the bot can draft the email and the workflow, I still decide whether it ships.
Technical barriers drop when the same bot can use more than one path into HubSpot. HubSpot's remote MCP server at mcp.hubspot.com went generally available on April 13, 2026. It lets an MCP-compatible AI tool read and write CRM objects over OAuth, with the connected user's permissions respected. HubSpot documents that path in its MCP overview. When MCP covers the object and the scopes, Herbert can query and draft through that door.
When MCP does not cover the object, or scopes are missing, we use a private-app API key or Service Key path for the same account. That is the second door. It is still authenticated access I control, not a shared password in a chat. When the API is blocked, the UI is the third door. Herbert can drive the front end for the jobs the API will not touch, or for the screens where a human still needs to see the record.
Concept boards. Not a live portal capture. Tokens and Hub IDs hidden.
Three doors are the point. One door fails often enough that partners who only have UI access spend hours of clicking and rework on the same discovery. Partners who only have API access get stuck when a required screen is not in the docs. I keep all three, and I still gate live writes. Permissions in HubSpot still apply. Sensitive data restrictions on MCP still apply. None of that is optional because the bot is convenient.
I posted the template publicly as a HubSpot expert for Solutions Partners with client accounts via API key, MCP, or the UI. Official @grok replied on that thread. HubSpot blogs cannot true-embed X cleanly, so here is the reply as text, then the links.
Three access paths for the same HubSpot expert bot is a smart setup. API key, MCP, or UI all leading to client-portal native guidance keeps things flexible for Solutions Partners without overcomplicating the workflow.
My post (includes the template card): https://x.com/derek_all_gusto/status/2096257577390608841. The @grok reply: https://x.com/grok/status/2096257675222712691. That is social proof of the three-door framing, not a substitute for discovery in your portal.
The anonymized example that follows is ticket-status customer notification emails in a client portal. The ask sounded simple: when a ticket moves, tell the customer. The portal already had stages, an existing Off workflow that would have double-sent if we built a second one on top, a sending domain to confirm, and no transactional email add-on, so the path had to be marketing emails with the right enrollment rules. If we had skipped discovery, we would have built a second writer on the same stage change and called it done.
Discovery means naming the object and the writers before anyone drafts copy. Which pipeline and which stages fire a customer email. Which workflow is already Off but still load-bearing if someone turns it on. Which domain will send. Whether transactional email exists on the account, or whether we are on marketing emails with unsubscribe and branding constraints. I will not invent a transactional path the portal does not have. If the add-on is missing, we say so and design for marketing emails, or we stop until licensing matches the job. Drafting copy before that inventory is finished is still the wrong order.
We created a property to carry the status the emails needed, four emails for the stages that deserved a customer message, and a workflow left Off for the client to activate with us. Domain skip for internal addresses so staff did not get customer copy. Greeting simplified when the custom tokens were not available in the UI, rather than inventing merge fields that were not there. That is the build. It is also the restraint.
Leaving the workflow Off is not unfinished work. It is the human gate. Activate-with-us means someone on their side and I are both looking when enrollment starts. A bot that turns the workflow on the moment the emails look pretty is how you get four notifications on a ticket that already had an Off workflow waiting to collide. Document what was built, what was refused, and what still needs a person before go-live. Their team should be able to run it when I leave.
I will not invent hours or a percentage for this post. What I will say is qualitative and true: the same discovery and build used to mean hours of clicking and rework in the UI alone. Opening stages, hunting the Off workflow, drafting four emails, checking the domain, simplifying the greeting when tokens were missing. With Herbert on MCP, API, and UI, that path is shorter because the bot can pull what exists, draft what is missing, and leave the activate step for a person. The savings are in the clicking and the rework, not in skipping discovery. If you skip discovery, you buy the double-send back.
If the portal is already full of Off workflows nobody owns, properties with two writers, and a ticket pipeline that does not match how support actually works, staffing a bot to add four emails encodes the mess. That is a HubSpot portal audit: what is broken, what to fix first, what not to rebuild. Herbert can help inventory. Herbert should not be the reason you skip the inventory.
Do not hire a bot build to paper over undocumented automation. Do not hire me to turn on a workflow until we know which Off workflows would collide. If the objects themselves are wrong, stop at architecture, not at email copy.
Is Herbert replacing you in our portal?
No. I still own the work and the live-write gate. Herbert is how I operate faster once the job is scoped. Reads and drafts can move without me clicking every screen. Anything that changes live records in your portal needs my yes. If a partner tells you their bot ships live without a human gate, ask who is on the hook when the double-send hits customers.
Where do I get the Grok Bot template?
The public template for Herbert is here: https://x.ai/bot/zFDmYYQKE8dUS9Z8r2LAd. Install it, connect the account doors you actually have, and keep a human gate on live writes. The template does not remove discovery or activate-with-us.
Do we need HubSpot MCP for this?
Not always. MCP at mcp.hubspot.com went GA in April 2026 and is one door. Private-app API and the UI are the other two. The useful setup is whichever doors your scopes and objects allow, not a single connector as a religion. If MCP cannot see the object, we use another door. If no door can see it safely, we stop.
Why leave the workflow Off?
Because enrollment is the risk. Emails and a property can sit ready. The workflow is the writer that starts mailing customers. Activate-with-us means we turn it on together after we confirm stages, domain, and that no Off workflow will collide. Pretty drafts are not a go-live.
What if we already have a notification workflow?
Then discovery found it, and we do not build a second one on the same trigger. We either fix the existing Off workflow, retire it in writing, or stop. Two writers on the same stage change is how customers get two emails for one status. That is automation without babysitting, not a bot flex.
Can the bot invent hours or savings for the SOW?
No. If I do not have a hard hour count from a scoped job, I say hours of clicking and rework, not a number I made up. This post does not invent dollars or percentages either. A SOW gets real scope after discovery, not after a blog example.
Who logs into the client portal?
I do, through Herbert and through my own access when needed. All Gusto does not hand client portals to juniors or offshore. Ask any HubSpot Solutions Partner for the names of the people in the portal, not the names on the website. The person who can open the Off workflow and tell you which property it writes is the person you are hiring.
Is this the same as buying a HubSpot AI feature?
No. HubSpot's MCP server is a connection HubSpot hosts. This Grok Bot is how I use that connection, plus API and UI, inside client work as a Solutions Partner. Buying HubSpot AI features does not by itself give you discovery, an Off workflow inventory, or a human gate on activate. Those are practice, not product.
If you want ticket notifications, a cleaner automation stack, or a portal that can be operated without hours of clicking and rework on every small job, tell me what already exists Off in the portal. I will tell you whether to build, to leave it Off until we activate together, or to audit first. The automation pillar is HubSpot automation without babysitting if that is the fight you already have. The Grok Bot template is here if you want the same three-door starting point.