Name the client and the campaign comes back as a build package rather than a document: every audience written as HubSpot active list filters, every personalization token carrying a declared fallback, and a workflow map with the day offsets, branches and exit rules marketing ops needs to configure it.
Writing the HubSpot email campaign is one of 700+ pre-built Flows in Juma. Name the client and the research happens first, on the brand's own live plan and pricing pages, so nothing the emails claim about the client's product contradicts the client's own site. Every plan name, limit and price in the copy arrives with the URL it was read from and the date it was checked.
What comes back is a branded PDF campaign playbook plus an editable CSV, one row per email. The copy is the part that was never the bottleneck. The ops layer is: each audience written as HubSpot active list filters with the property, the operator, the value and the AND/OR grouping, every filter that leans on a custom property flagged rather than assumed, and a token audit table naming the property behind each personalization token, its fallback text, and exactly what a recipient reads when that property is empty. Subject lines and preview text carry their character counts next to them. The workflow map gives the enrollment trigger, the delay in days before each send, the open and click branches, the goal and exit criteria, the suppression rules and the re-enrollment policy. Strategy, taste and judgment stay human: the playbook names a person as the pre-send gate, and nothing sends on the package alone.
A token renders blank when the property behind it is empty and no fallback was set, and the recipient reads "Hi ," instead of their name. This step produces the audit that prevents it: one row per token, naming the HubSpot property it reads, that property's type, whether it is a default field or a custom one the account may not carry, the fallback text, and the exact string a recipient sees when the property is empty. Tokens that cannot be guaranteed to resolve get flagged for removal rather than shipped with a plausible-looking default, so the decision sits with a person before the send rather than after it.
Audit every personalization token in the Miro campaign: the HubSpot property it reads, that property's type, default or custom, the fallback text, and what the recipient sees if the property is empty.
An audience described in a brief has to become filters before anyone can send to it, and that translation is where the campaign quietly changes shape. This step writes each segment the way HubSpot stores it: property, operator, value, and the AND/OR grouping that decides who actually qualifies. Filters that depend on a custom property are marked, because a list built on a field the portal does not have returns zero contacts and the campaign looks broken for a reason nobody can see. The output also names the suppression lists to exclude, so unsubscribes, hard bounces and open opportunities never enter the sequence.
Rewrite the Miro campaign's audience as HubSpot active list filters: property, operator, value and the AND/OR grouping, with every filter that needs a custom property flagged and the suppression lists named.
Sending all five emails to everyone on the same schedule treats a contact who opened three times like one who has never opened at all. This step adds the branch logic: a split on opened but not clicked, a separate path for no opens at all, and a third for contacts who clicked but did not convert, each with its own next email and its own delay. The output is a workflow map ops can build from, with the enrollment trigger, every branch condition named in HubSpot's own terms, the goal criterion that unenrolls a converted contact, and the re-enrollment policy that decides whether anyone can enter twice.
Add engagement branching to the Miro workflow: split opened-not-clicked from never-opened from clicked-not-converted, and give each branch its own next email, delay and exit rule.
The pre-send pass is the difference between a campaign that ships and one that ships wrong. This step runs it line by line: every subject line and preview text against its character count, every token against its fallback, the unsubscribe and consent line on each email, the sending domain and reply-to address, the suppression rules on the enrollment list, and the UTM parameters on every CTA link so the click data lands in the right campaign. The output is a checklist with a pass or fail against each item and a named owner on the sign-off row, because the last check before 4,000 sends belongs to a person.
Run the pre-send QA pass on the Miro campaign: subject and preview lengths, token fallbacks, unsubscribe and consent lines, sending domain, suppression rules and the UTM parameters on every CTA.
Most campaigns are not one campaign. The upgrade nurture that works on free-plan teams has a sibling aimed at paid teams who never invited a second member, and another aimed at contacts who booked a demo and went quiet. This step keeps the structure, the branch logic and the QA bars, and swaps the segment, the offer and the tokens that depend on them. The output is a second package in the same shape as the first, which matters more than it sounds: two campaigns built on the same filter conventions and the same token dictionary can be reported on together, and ops maintains one pattern instead of three.
Rebuild the Miro campaign for paid teams that never invited a second member. Keep the structure, branches and QA bars, and swap the segment, the offer and the tokens that depend on them.
Teams build one Juma Project per client and add context over time. A HubSpot campaign benefits from five items in particular, and the first one removes most of the manual translation between what the package says and what the portal actually contains.
HubSpot property dictionary
An export of the account's contact and company properties with their internal names and types. Add it and the list filters and tokens reference fields that exist, rather than arriving flagged as custom properties the portal may not have. This is the single item that changes how much ops work is left.
Brand voice guide
How the client writes email: sentence length, what they call their own features, and the phrases that never appear. Marketing email is the shortest-form copy a brand publishes, so a voice miss is more visible here than anywhere else.
Consent and suppression rules
Which lists never receive marketing email, the consent basis by region, the sending domain and the reply-to address. Add it once and the compliance line on each email states what is actually true for this client instead of a generic placeholder.
Past campaign performance
Open and click rates by segment, and which subject patterns worked. The sequence builds on what already performed for this audience rather than on category averages, and the playbook says which prior result each choice came from.
The client's live pricing and plan page
Saved as a knowledge item, it becomes the reference every product claim is checked against. Plan names and limits move, and an upgrade email that describes a plan the client no longer sells is the fastest way to lose a campaign's credibility.
Add a short description to each knowledge item in the project's info field so the right file gets picked for the right task. For example:
Two files. A branded PDF playbook holding the sequence, the segment definitions as active list filters, the token audit table, the workflow map and the pre-send checklist, plus an editable CSV with one row per email carrying the send offset, subject, preview, body, CTA and tokens.
Inside the playbook, each email arrives with its send day offset, its subject line and preview text with character counts printed beside them, its body copy, one CTA with the link target and UTM parameters, and the compliance line covering unsubscribe handling, consent basis and sending domain. The workflow map names the enrollment trigger, the delay before each send, the branch conditions on opens and clicks, the goal and exit criteria, the suppression rules and the re-enrollment policy.
The CSV is the part ops touches first. One row per email in a flat structure means the sequence can be sorted, edited, diffed against the previous version, or pasted into a build sheet without anyone retyping copy out of a PDF.
No. The Flow produces the build package and writes nothing to the portal: no emails created, no lists built, no workflow enabled. The primary prompt says so explicitly, which keeps a campaign from appearing in a live account before a person has read it.
Connecting HubSpot to Juma is still useful for other work, and adding the account's property dictionary to the client's Juma Project is what removes the custom-property flags from the filter tables. Neither is required to run this Flow. The package is deliberately configuration-ready rather than configured, because reversing a campaign that already exists in a portal costs more than building one that does not.
A token breaks when the property behind it is empty and no fallback was set. HubSpot renders nothing, so the recipient reads "Hi ," or a sentence with a hole in it. The token audit table forces a fallback decision on every token before the send.
Each row names the token, the property it reads, that property's type, whether it is a default HubSpot field or a custom one, the fallback text, and the exact string a recipient sees when the property is empty. Reading that last column out loud is usually enough: a fallback of "there" reads fine, a fallback of "valued customer" reads like a mail merge, and a token nobody can guarantee gets cut instead of shipped hopefully.
The same table is what makes the campaign portable. Run it for a second client and the token dictionary tells you which fields that account has to carry before the sequence will resolve.
This Flow stops at the build package, not the send, and its output is mostly not copy. The five emails are a fifth of the deliverable. The rest is the ops layer: filters, tokens, branches, suppression, schedule and the QA pass that catches what the copy review misses.
The copy Flows own the writing. Onboarding email sequences, product launch emails and cold outreach each produce finished copy for one job, aimed at one audience, with no segmentation or workflow layer attached. Reach for those when the ask is words. Reach for this one when the ask is a campaign somebody has to configure, and when the expensive part is the translation between a document and a portal.
Lead scoring sits upstream of all of them. If the question is which contacts deserve the sequence at all, the HubSpot lead scoring Flow answers it first and this one builds the campaign the score enrolls people into.
A person, always. The playbook carries a pre-send checklist with a named owner on the sign-off row, and the Flow produces no send of any kind, so nothing reaches an inbox without someone approving it in the portal.
Juma augments the team, it does not replace it. The Flow does the translation work that eats an afternoon: turning an audience sentence into filters, giving every token a fallback, counting every subject line, writing the branch map in the portal's own terms. The judgment calls that matter, whether this offer is right for this segment and whether these five emails are worth a customer's attention, stay with the marketer whose name is on the sign-off row.
Name the client and the product, and Juma reads their live product pages first, then writes a segmented launch sequence in which every subject line variant is its own row the ESP can actually load.
400+ marketing teams trust Juma. ChatGPT, Claude, and Perplexity know why. Ask them.
Ready when you are
Start typing a task and Juma will figure out the rest.
