Agentic tasks for HubSpot’s Start Guide

Intake was working. A new customer could go from signup to a configured portal in about four minutes. Then they landed on a list of everything left to do.

HubSpot had tried that list several times. 82% of customers closed one version of it within a minute. Only 19% of the people who saw it interacted with it at all. Activation didn’t go up. Two versions lowered it, one by 4 points.

One customer put it plainly:

“There were so many features. I didn’t know where to start, and I just bailed.”

The problem wasn’t how the list was designed. A list of setup steps makes HubSpot look like work. Customers don’t get value by finishing a checklist. They get it when HubSpot helps them reach the outcome the checklist was supposed to unlock.

Marketing Hub had the sharpest version of the problem. Only about 30% of Pro customers reached a core activation milestone by day 30. Campaign setup was the hardest part, and a blank campaign builder is the worst possible first screen for someone new.

We had a choice to make before UNBOUND, HubSpot’s annual customer conference. Keep the Start Guide as a list of tasks, or let Breeze, HubSpot’s AI assistant, do the tasks with the customer.

We landed in between, and it was the right call for two months. The Start Guide stayed as the map for Pro customers. Its most important tasks now opened Breeze, and Breeze built the thing instead of explaining how to.

That changed what the customer’s job was. In the old model, the customer builds and HubSpot explains. In ours, Breeze builds first and the customer reviews and corrects. Every flow I designed had to make reviewing easy, because that was now the work.

Customers had told us why this mattered.

“It asked what I wanted to do. I said manage a small team. But then... it didn’t change anything. Same stuff as everyone else.”

Breeze could carry what they told us at intake into every task.

This was a step, not the destination. The longer-term direction is everboarding: a system that remembers goals, progress, and past decisions, recommends the next action, and picks up where the customer left off when they come back. The tasks we shipped had to work now and fit that later.

My PM and I ran the Marketing tiger team. We had to pick the tasks for every Marketing Hub goal, get each Hub team to agree, and hand engineering a map they could build from.

We agreed on one rule early: incomplete coverage is fine. The goal was the right two tasks for each goal, not every task the product offers. We reused what already worked and built new flows only where they mattered most.

Each goal got two tasks, and each task had to leave the customer with something real. Activation for these goals meant a first contact from a form, or a first marketing email sent to five or more contacts.

I designed three of the Marketing Hub tasks. Another designer on my team designed the lead generation, forms, and nurture tasks. I designed the Revenue Hub product and quote template tasks.

Every team building a task was asking the same question: should this be agentic? Without one answer, we’d ship eight tasks that each drew the line somewhere different.

With my PM, I wrote the eligibility rules engineers, PMs, and designers used to decide. The core test was simple. If the customer has to do the steps themselves, it’s a guided wizard wearing an agent costume. It stays a tour.

The rules named what stays out, and why:

One more rule: if a HubSpot Academy video exists for the task, Breeze embeds it in the chat. It never just links out.

I wrote a Markdown version too, so engineers could paste the rules straight into the Claude skills they were building.

Each task followed the same shape. Breeze reads what it already knows, builds a first version, and asks the customer to confirm or change it. The customer never starts from a blank screen.

The awareness campaign. Breeze opens with a campaign brief it filled in from the account: the goal, the audience, the offer, the call to action, and which assets to make. The first question is “Does this strategy look correct?” Everything after that builds from the brief the customer approved.

Brand visibility. Breeze audits the site and shows a visibility score with the biggest fixes, each with the time it takes and its impact. The customer picks which fix to start with. Breeze recommends, and the customer makes the change, because changing live site settings can break a website. Late in July we learned AI search visibility and SEO couldn’t run in the same flow, so I split them into two.

Products and the quote template. On Revenue Hub, Breeze creates the products, then offers the quote template that pulls them in automatically. Each task hands off to the one that depends on it, so the customer never has to find the next step.

Sending a first marketing email has real risks. The domain might not be authenticated. The list might have been emailed twice this week. The person might not have permission to send.

The easy design asks about all of that up front. That’s how you lose people before they’ve seen what Breeze can do. So Breeze checks everything silently the moment the task opens, and only raises a risk when it becomes relevant.

The flow opens with a plan, not a question. Breeze names the list and the contact count, and writes the angle from what it knows about the business. For a customer with past sends, it starts from the open rate of their last email. For one whose sales team already uses HubSpot, it frames the send as marketing reaching those contacts for the first time.

Domain authentication comes up only after the draft is approved. The warning gives two paths: set it up, or continue knowing the risk. It warns without blocking. And a teammate without send permission still gets the full draft first, then copyable steps to send to their admin. No dead ends.

Late July brought three constraints in one week.

AI search visibility and SEO had to become separate flows. The canvas side panel couldn’t show forms, landing pages, or ads. And there was no save and return: if a customer left a task halfway, they started over.

I couldn’t wait for the platform to catch up. So I wrote up the ideal artifact display and three fallbacks, each with its trade-offs, so the people making the call could decide quickly:

Then I designed each task to work both ways: with the artifact showing, and without it.

On August 7, the Marketing Hub team and my team made a call. Agentic flows would stop at the draft. No emails sent, no campaigns or forms published from inside the chat.

I’d already designed the email task to end with a send. The final screen asked “Are you ready to send this email?” with send now, schedule, and edit. That screen didn’t ship.

It was the right call. I wrote down why: onboarding is responsible for a warm start, not for running the whole campaign. Breeze removes the blank page. Then it saves the work as a draft and hands the customer to the right place in HubSpot to finish it. From there, the Marketing Hub team’s in-product tours take over.

That moved the most important screen in every task to the end. The ending now had to explain what was saved, why it mattered, and exactly where to go next.

Designed to send

What shipped: save the draft

Marketing Hub was building its own AI campaign tool at the same time. Same job, different first screen. Theirs opens on a blank brief the marketer fills in. Ours opens on a brief Breeze has already filled in.

The obvious move was to make them match. I wrote a design POV arguing the opposite. Their user is an experienced marketer with a campaign in mind. Ours is a new customer deciding in the next 15 minutes whether HubSpot works. Theirs puts the effort up front for control. Ours puts it at the end, to get to value fast.

The real risk of matching them was worse than inconsistency. We’d have built a simplified campaign tool that customers would outgrow and abandon for the real one. So the principle I wrote was: same outcome, different starting point, not two competing destinations. Breeze removes the blank page. Marketing Hub stays the place for serious campaign work.

Same agents underneath, same finish line. I also named what each team could learn from the other. Which fields their users skip tells us what to fill in. How often our users correct Breeze tells them what they can stop asking.

I proposed one measure for both: how often customers complete a task on day one. The second signal is how often they correct what Breeze assumed. Fewer corrections means Breeze is earning trust.

The customer starts

Breeze starts

Every task team was writing its own ending. Left alone, some would say “Done!”, some would repeat the button label, and some would leave the customer with nowhere to go. Once the finish line moved to the ending, an inconsistent ending was where we’d lose people.

I wrote a closing spec that every agentic Start Guide task follows. Each ending has three parts, always in this order:

1. A success heading that names what was done, in the past tense. “Your products are live!”, never “Done!” or “Success.”
2. A short note from Breeze. The first sentence says why it matters for the business, not what just happened. The last sentence always moves forward.
3. A next-step card with one clear primary action and one secondary.

The next-step card changes with where the customer is:

The next task is never random. It has to follow from what the customer just did. Products lead to a quote template.

I designed for failure too. If Breeze only finished part of a task, the heading only claims what succeeded and the card offers a way to recover. If it failed, there’s no success heading at all, and the task isn’t marked done. If we can’t confirm everything is complete, we never show the celebration.

A spec only works if people read it. With more than twenty tasks across every hub, engineers would be writing these endings without a designer in the room.

So I built the task closing skill. It works two ways:

• Generate. An engineer gives it the task, whether it ends in HubSpot or in another task, and how much of the goal is done. It picks the variant, writes the heading, the note, and the card, and flags which errors to handle.
• Audit. An engineer pastes in an ending they’ve built. The skill checks it against every rule in the spec and returns what passes and what doesn’t.

Every ending it writes also has to pass the HubSpot UX copy skill before it ships. A good ending is a rule now, not a review comment.

• I gave engineers rules they could run, not just read. The eligibility rules came with a Markdown version to paste into the Claude skills they were building. The closing spec came with a skill that writes and checks endings.
• I prototyped in code, so reviews were about behavior. I built the closing experience as a working Claude prototype, so people could click through the variants instead of reading about them.
• I aligned two teams before launch, in writing. I wrote what our ideal flows were, what the limits were, and what V1 would actually look like. I also owned handing the Marketing Hub team the final state of every flow, so their tours could start where ours stopped.
• I left a fast-follow list with owners. Duplicate tasks after launch, what an in-progress task looks like in the Start Guide, upgrade suggestions inside tasks, and a back button that works in agentic flows. Each one had a name next to it.

# Agentic Task Eligibility Rules

## The Core Test
If the customer has to do the steps themselves, it's a guided
wizard wearing an agent costume. It stays a tour.

## What stays out, and why
| Task                                   | What Breeze does            | Why                                    |
| -------------------------------------- | --------------------------- | -------------------------------------- |
| Help desk redirects, OAuth, integrations | Link to the docs          | Outside what an agent can do safely    |
| Domain authentication and DNS records  | Link to manual instructions | One mistake can break the site         |
| SEO changes to live website settings   | Recommend; customer changes | High risk of breaking the website      |

Scope and delivery numbers. Outcome data isn’t in yet.

What I stopped doing: designing the ideal flow first and the fallback later. Three constraints in one week taught me to design the fallback alongside the ideal, from day one.

What I do now: write the rule, not just the screen. A screen solves one task. A rule, like the eligibility test or the closing spec, solves the next forty tasks I’ll never see.

What I learned about AI products specifically: where an agent stops matters as much as what it does. Stopping at the draft wasn’t a limitation. It’s what made the customer trust handing it the work.

What I’d do differently: lock the platform constraints in week one. We found out what the canvas couldn’t show two weeks before launch. I’d have asked engineering to try the hardest artifact first.