Email CRM

Creators were already segmenting their audiences. They were doing it in Mailchimp, with contacts they had exported from us.

---

At a glance

Role	Product Manager. Sole author of the PRD. Designed the contact data model, the segment builder, the sequence model and the plan gating.
Collaborators	Nelson, CTO (architecture and engineering delivery; joint deliberation on the post-launch abandoned cart model)
Shipped	13 August 2026, as part of Nestuge Plus
What it is	A contact database with lists, segments and trigger-based email sequences, built on top of a single automated welcome email and manual broadcasts
What I owned	The data model, the hierarchy rules, what each plan gets, and the resolution of six open questions
What I did not own	Architecture, sending infrastructure, engineering delivery

---

Context

Before this, Nestuge’s email tooling did two things: sent one automated welcome email when someone bought, and let creators write and schedule one-off broadcasts. Both still exist and still work. Nothing here took anything away; the CRM is a layer on top.

That is enough to make an announcement. It is not enough to run a business. A creator with four products, a paid hub and a membership has an audience distributed across all of them, and no way to see who bought what, who is engaged, or who to talk to next.

---

The problem

Feedback sessions and logged user requests. Creators had no way to segment their audience or automate follow-up communication beyond that single welcome email, and no way to target a specific subgroup at all. This surfaced in feedback sessions and across our pool of user request data.

The consequences were concrete. Revenue that already existed went uncollected, because nobody was running upsell or re-engagement flows. Support requests came from creators trying to track their audience by hand. And there was a competitive gap against dedicated tools like Mailchimp, ConvertKit and Kajabi, which creators could use instead and did.

Our own integration data. Nestuge integrates with Mailchimp and SendGrid, so we could observe what was flowing out. Creators were exporting their contacts and doing audience work in tools built for it.

That second signal is the one that made the case, and it is the same pattern that justified our AI agent on a different surface: the job was already being done, just not by us. Every export was a creator telling us that the platform where their audience lives is not the platform where they manage it. Beyond the missed revenue from upsell and re-engagement flows nobody was running, it is a slow structural risk. The tool that holds your audience relationships eventually holds the relationship.

---

Constraints

• Segmentation is a query-builder problem, and creators are not analysts. Any honest version of this feature asks users to construct conditional logic over a relational structure. That is the central design difficulty and it does not go away by hiding it.
• The existing simple email system had to keep working for creators on the pay-as-you-go plan.
• The hierarchy already existed and was not designed for this. Products, hubs, hub groups, payment plans and memberships each had their own structure. The contact model had to sit on top of all of it without asking anyone to reorganise anything.
• Two plans, one interface. The feature had to be legible to creators who could not use it.

---

Decisions

1. Build every list for them, and let them build their own

At stake: whether a creator’s first session ends with a populated audience or an empty state and a builder.

A list is created automatically for every product and every hub. Segments are created automatically for each payment plan, each hub group, abandoned carts, and subscription status. A creator who has never opened the CRM already has a structured, populated audience the first time they land on it.

Alongside that, they can build their own: custom lists by CSV upload, and custom segments through a condition builder.

Why both, rather than picking one. Nestuge’s creator base is not one population. Some run sophisticated operations and want to construct exactly what they want. Most want the thing to already be there. Sundar and Marathe’s work on personalization versus customization found that power users rated content quality higher when the interface was customizable, while non-power users preferred system-tailored content. Those are not competing design philosophies to choose between. They are two audiences on the same platform, and the product had to serve both at once: personalization as the default, customization as the ceiling.

What I gave up: a system that generates lists and segments for everything produces clutter for creators with many products. The auto-generated set is opinionated, and some of those opinions are wrong for some creators.

2. Segments cannot contain segments

At stake: how much expressive power to allow.

Global Contacts sits at the top. Lists derive from Global Contacts. Segments derive from Global Contacts or from a list. A segment can never be the parent of another segment. The hierarchy is three levels and it stops.

The reasoning was flatness for its own sake. Allow segments to nest segments and the trail never ends: a creator can build a segment of a segment of a segment, and every one of them needs a name, a provenance and a rule for what happens when an ancestor is deleted. Every ambiguity in the model multiplies down that chain. And no creator has ever needed it. The expressive power that nesting buys is power over a use case that does not exist.

What I gave up: genuine expressive range, and the ability to say yes to a future request without revisiting the model.

What I bought, which I did not fully appreciate at the time: a rule strong enough to decide a question I had not yet answered. See the next fork.

3. Hub groups as segments, forced by the rule above

At stake: the one place the model did not resolve cleanly.

This is the fork I would put in front of anyone who wants to know how I think, because the PRD contains both the confusion and the answer.

Section 6.1 records the problem as it stood while I was still writing:

One potential issue: How to manage hub groups in this situation. Should they be lists or segments, since they are within a hub but also have their own payment plans. If they are lists, then we can create segments from them based on the plans, but we need to then resolve the provenance hierarchy with the parent hub.

The bind: hubs were already lists. Hub payment plans were already segments. But some hub groups are paid and carry their own payment plans. Treating a hub group as a list would mean a list nested inside another list’s territory, with an unresolved provenance hierarchy. Treating it as a segment would mean its payment plans become segments of a segment, which fork 2 forbids.

The resolution, recorded in Section 11 as OQ-1: hub groups are segments. The rule from fork 2 held, and the group’s payment plans do not get their own segment layer. The constraint decided the case.

Why I kept the unresolved paragraph in the document rather than editing it out: a spec that only contains answers hides where the difficulty was. Anyone reading Section 6.1 and Section 11 together can see the shape of the problem and the reasoning that closed it.

4. Folding the old welcome email into the new model

At stake: whether to run the new system alongside the old one.

The existing automated welcome email became the default sequence for every product and hub contact list, with its entry criterion predefined as purchase of that product. Creators can then extend it: add emails, define exit criteria.

It could have stayed where it was. Adding a sequences system beside an existing welcome-email system would have been less work and less risk.

I folded it in to reduce cognitive load. One place where email lives, one place where email performance is visible. A creator asking “how is my welcome email doing” should not first have to remember which of two systems it belongs to. The cost of two systems is not paid by the team that builds them; it is paid by every creator who has to hold both in their head.

5. What the free plan gets, and what it can see

At stake: gating that funds the business without making the cheaper plan feel punitive.

Nestuge Plus is the subscription plan with access to all features. Pay-as-you-go creators have some features gated. The CRM is one of them, and gating it meant deciding exactly where the line falls.

• The CRM interface is visible in a locked state with an upgrade prompt, rather than hidden
• The existing simple email system stays fully functional, so no existing workflow breaks
• Default welcome sequences remain visible but not editable
• PAYG creators see a read-only count of their contacts (OQ-4)

That last one is the deliberate part. Showing a creator that they have 1,400 contacts they cannot yet organise is more persuasive than any description of the feature, because the number is theirs. It is an honest itch: the value is real, it is already theirs, and the plan is what unlocks acting on it.

The principle was giving PAYG creators enough value for what they pay while sustaining the business goals. Nothing they had was taken away.

6. Five things this deliberately does not do

Non-goals, written down with reasons rather than left as silence: no two-way contact communication, no A/B testing, no native template builder, no external CRM sync, no behavioural triggers beyond purchase and list addition.

One of them carries a condition rather than a flat no. A/B testing “may be introduced as a fast follow based on adoption data.” That is the same discipline I applied to deferring the integration layer on our AI agent: a deferral should name what would bring it back. Deferrals without a condition are rejections that nobody wants to defend, and they are how backlogs fill with items no one will ever revisit.

The smaller decisions

Decision	Reasoning
Sequences enrol individual contacts, not lists	A list is a moving target. A contact either qualifies or does not, and can be evaluated on their own
Exit criteria remove a contact at the point they qualify	A contact who no longer belongs stops receiving the sequence mid-flow rather than finishing it
Contacts already enrolled are not retroactively re-evaluated when a list changes	Enrolment is the commitment. Re-evaluating retroactively means a creator editing a list silently changes what people already in flight receive
Segments visually trail from their parent list in the table	The provenance is the hard part of the model, so the interface shows it rather than describing it
CSV column headings become contact profile parameters on import	The creator’s own structure survives the import rather than being flattened
Bulk removal by condition, for example all unsubscribers	List hygiene at the scale it actually happens
Percentage and absolute metrics toggle	Rate and volume answer different questions, and a creator with 40 contacts needs the second one

---

The open questions, and who resolved them

The PRD’s Section 11 resolves six questions that product and engineering had to deliberate on rather than decide unilaterally. They are in the document with their answers.

	Question	Resolution
OQ-1	Are hub groups lists or segments?	Segments. See fork 3
OQ-2	What happens to contacts when a list is deleted?	Warn, then delete from Global Contacts
OQ-3	What happens to a contact enrolled in a sequence whose entry list is deleted?	Warn at the point of deletion that the contact will be removed from any sequence they belong to, then remove on confirmation
OQ-4	Should PAYG creators see their contact count?	Yes, read-only. See fork 5
OQ-5	Do sequences need their own sending infrastructure?	No. Same pipeline as broadcasts
OQ-6	What accuracy is expected from IP-based location targeting?	99%, surfaced at country level

Three of these are destructive-action questions, and all three resolve the same way: warn, then honour the decision. Not blocked, not silent. A creator deleting a list is allowed to delete the list, and is told what else it takes with it.

I have included this section as an artifact because it is the part of the document I would most want to be read. Most specs I have seen either omit their open questions or leave them open permanently. Naming a question, deliberating it with the people who have to build it, and recording the answer in the same document is the difference between a spec and a wish list.

---

Targets set before building

The PRD committed to falsifiable targets with evaluation windows, before a line was written.

Metric	Target	Window
Plus creators with ≥1 list or segment configured	60%	60 days
Plus creators with ≥1 active sequence	40%	90 days
Segment creation completion rate	≥70%	60 days
Average unique open rate on sequence emails	≥35%	90 days
Subscriber retention delta, CRM users vs non-users	+15%	90 days
PAYG-to-Plus upgrades attributable to CRM gating	15% of PAYG base	90 days
Support tickets re manual audience tracking and follow-up	-30%	60 days

Segment creation completion rate is the one I care about most, and it is the one most likely to expose a design failure rather than a demand failure. If creators start building segments and do not finish, the builder is the problem, not the feature.

---

What shipped

13 August 2026, with Nestuge Plus. Full contact database with auto-generated lists and segments, the custom segment builder with ten operators and AND/OR chaining, CSV import and export, contact drilldown with bulk removal, multi-step sequences with entry and exit criteria and relative send timing, per-email and per-sequence metrics, and draft, publish, disable and duplicate states.

Reception has been positive and we are still collecting feedback. The parts creators respond to are the ones that removed setup work rather than added capability: audiences that were already organised on arrival, and being able to see how a welcome email is actually performing for the first time. It is early, the evaluation windows have not closed, and I would rather say that than claim a result.

---

After launch: the abandoned cart model

Post-release work, from feedback and observation, deliberated with Nelson.

Abandoned carts existed as a default segment from day one. What was missing was that having the segment does nothing on its own. Somebody still had to build a sequence for it, which meant recovery emails only happened for creators who thought to set them up.

The rules we landed on:

• Abandoned cart segments auto-generate for both PAYG and Plus creators, on a product’s first abandoned transaction. Not gated, because a creator losing a sale should not have to upgrade to find out
• Contacts leave the segment 30 days after the abandoned transaction, so it stays a recovery window rather than a graveyard
• A global abandoned cart sequence runs by default, so recovery happens whether or not the creator does anything
• A “Create a sequence” button on lists and segments, auto-selecting that list or segment as the entry criterion. The old path required creating a sequence and then finding your way back to the segment
• No “Create a segment” option on the global abandoned cart list, because segmenting it serves no purpose and every unnecessary option costs attention
• When an abandoned cart segment gets its own published sequence, it leaves the global one. If that sequence is later deleted or disabled, it rejoins
• Once an abandoned cart segment has a sequence, “Create a sequence” becomes “View sequence”, and that segment stops appearing as an available entry criterion elsewhere. Each abandoned cart segment belongs to exactly one sequence at a time. This constraint applies to abandoned cart segments only; ordinary lists and segments can feed as many sequences as a creator wants

Those last two are one idea: every product always has exactly one abandoned cart sequence running, and the creator can replace it but cannot switch it off by accident. Customisation without a hole in the floor. The rejoin rule is what makes it safe, because the failure mode we were designing against is not a creator who chooses to stop recovery emails. It is a creator who disables a sequence to edit it and silently loses recovery for a product for three weeks.

The constraint is deliberately narrow. Abandoned cart recovery is the one place where a product must always have exactly one sequence running, so that is the one place the model restricts a segment to a single sequence. Everywhere else, a creator can point as many sequences as they like at the same list or segment. Constraining the whole system to make one case safe would have been the easier rule to write and the wrong one to live with.

Within that scope, though, it is the same instinct as forbidding nested segments: reduce the number of states the model can be in, and most of the confusing cases stop existing.

---

Research and theory

Informed the decisions

Heuristic evaluation of leading CRM tools. Structured heuristic work on SendGrid and Mailchimp, both of which Nestuge integrates with and which we had observed over a long period. This is the direct source for the builder patterns, the sequence model and the metrics surfaced per email and per sequence.

Sundar, S. S., & Marathe, S. S. (2010). Personalization versus customization: The importance of agency, privacy, and power usage. Human Communication Research, 36(3), 298–322. https://doi.org/10.1111/j.1468-2958.2010.01377.x

Power users rated content quality higher when the interface was customizable; non-power users preferred system-tailored content. Applied to fork 1: rather than treating this as a choice, build both layers and let a creator’s own sophistication decide which they use.

Applied afterward

The Boolean AND/OR problem. Hearst’s survey of query specification interfaces notes that studies have repeatedly found most users have great difficulty specifying Boolean queries and often misjudge what results they will get. The specific failure is well documented: colloquial “and” means union, while Boolean AND means intersection. A user wanting records from two cities will naturally write “Boston AND New York” and receive nothing.

Hearst, M. A. (1999). User interfaces and visualization. In R. Baeza-Yates & B. Ribeiro-Neto, Modern Information Retrieval. Addison-Wesley.

I did not have this framing when I designed the segment builder. It describes a live problem in what shipped. See below.

---

What I would do differently

Segment preview should have been P0, not P1.

The custom segment builder takes a target unit, one of ten operators, a value, and then chains conditions with AND/OR. It is the most powerful thing in the product and the most likely thing to fail quietly.

Here is the failure I did not design against. A creator wants everyone on the Monthly plan and everyone on the Annual plan. They build plan is Monthly AND plan is Annual, because that is what the sentence in their head says. No contact holds two plans, so the segment returns zero. Nothing is broken, nothing errors, and the creator’s most reasonable conclusion is that they have no customers.

I listed segment preview, a live contact count updating as conditions are added, in P1 as a nice-to-have. It is not a nice-to-have. It is the only thing standing between a creator and a silently empty segment, and it costs nothing to build relative to the builder itself. A live count that drops to zero the moment they add the second condition teaches them the operator in about two seconds, without anyone having to explain Boolean logic to a creator selling a fitness course.

The tell was in my own metrics table. I set a target for segment creation completion rate, which means I knew abandonment in the builder was the likely failure. I set up the measurement and then put the mitigation in the next tier down.

That is the mistake I would fix first, and I would fix it before any of the other P1 items.

---

Artifacts

• Email CRM PRD (redacted), including the open questions section and the resolutions
• Abandoned cart post-release model (redacted)

---

Attribution: I wrote the PRD and designed the contact model, the segment and sequence models, and the plan gating. Nelson (CTO) owned architecture and engineering delivery, and the post-launch abandoned cart rules were deliberated jointly. Where this case study describes system behaviour, it describes the behaviour I specified, not its implementation.