Customer Insights – Journeys versus a standalone marketing platform

What it does

This is the argument you have when a client already runs Dynamics 365 and someone in marketing already runs Mailchimp, HubSpot or Marketo. Both can send the email. The decision is about where the customer record, the consent record and the orchestration logic live, and who pays for the integration when they live in two places.

Key facts

Customer Insights is licensed at tenant level, not per seat. It does not appear under Licenses in the Microsoft 365 admin centre, only under Your Products, which confuses clients expecting a seat count.
The base Dynamics 365 Customer Insights licence covers both Journeys and Data under one purchase, but they meter separately: Journeys consumes Interacted People, Data consumes Unified People.
Base entitlement is 10,000 interacted people and 100,000 unified people, tenant-wide. Monthly interactions are entitled at ten times the interacted people count.
An interacted person is any contact, lead or profile that received an outbound interaction through Journeys in the last twelve months. They fall out of the count after twelve months of no interaction.
Quota is counted across every environment on the tenant — production, sandbox, developer and trial all draw on the same pool. Nobody expects this and it bites during a parallel-run.
Add-on packs exist for Interacted People (T1–T3), Unified People, and a 500,000 sending burst. Attach-priced offers carry identical entitlements to full-price ones; they are just cheaper for existing Dynamics customers.
Throughput is tied to the quota, not bought separately: up to 500,000 interacted people gives roughly 140,000 interactions an hour, and above that 500,000 an hour. Concurrent journeys divide that rate between them.
The service caps at 10 interactions per interacted person per month. If a client's send cadence exceeds that, the fix is more interacted people, not a support ticket.
Real-time journeys is a first-party Dataverse application. Triggers, segments, personalisation and consent all read Dataverse directly, with no connector, no sync window and no field mapping.

When to use / skip

My default recommendation: if the client's marketing is genuinely about the customer relationship — B2B nurture, service-driven messaging, events, anything where the sales team needs to see what marketing sent — use Customer Insights – Journeys and retire the standalone tool. The reason is not feature parity. It is that every standalone platform you keep creates a two-way contact sync, a consent reconciliation problem and an argument about which system is right. Those cost more over three years than the licence difference, and they never get properly finished.

Where I would do the opposite: high-volume B2C ecommerce with a mature ESP already wired into a storefront, a product catalogue and a recommendation engine. If Klaviyo or a similar platform is already sitting on the transactional data and the merchandising team lives in it daily, ripping it out to satisfy an architecture diagram is a bad trade. Same answer for a client whose marketing team is three people who have used HubSpot for six years and whose Dynamics footprint is Sales only — the migration cost lands entirely on the people least equipped to absorb it.

The genuinely hard middle case is the client who wants both: HubSpot for top-of-funnel demand generation, Journeys for lifecycle and service messaging. That can work, but only if you draw a hard line — one system owns each contact point's consent, and the other one respects it and never writes to it. Split ownership of consent is the failure mode that ends up in front of a regulator.

Be careful with the volume arithmetic before you commit. Ten interactions per interacted person per month sounds generous until you count a weekly newsletter plus an event campaign plus service notifications. And check whether the client's sandbox refresh cycle is quietly burning tenant quota.

Configuration decisions

Which system is the system of record for consent. One answer, written down, before anything is built.
Whether Customer Insights – Data is in scope at all, or whether Dataverse contacts are enough as the audience source. That decision changes the licence conversation and the meter you consume.
How many interacted people to buy, sized on twelve-month rolling reach rather than database size. Most clients over-buy because they count contacts.
Whether sandbox and dev environments are permitted to send at all, given they consume the same tenant quota.
If a standalone platform stays, which direction contact data flows and whether it is one-way. Two-way sync between Dynamics and an ESP is a maintenance liability.
Whether the sending domain is shared with the incumbent platform during any parallel run, and how the warm-up is sequenced.

Gotchas

Quota is tenant-wide. A load test in a sandbox reduces production headroom, and nothing in the UI makes that obvious until the month's numbers look wrong.
Throughput divides across concurrent journeys. A client running two 280,000-member sends at once gets roughly half the rate on each, then complains the platform is slow.
The twelve-month interacted-person window means quota consumption looks fine in month one and tight in month thirteen. Size for steady state, not launch.
Clients hear "one licence covers Journeys and Data" and assume one pool. The two meters are independent and you can exhaust one while the other is untouched.
Keeping a standalone ESP alongside Journeys means two suppression lists and two bounce histories. Deliverability problems then become unattributable.

Consultant notes

Get the licensing conversation done in week one with someone who can approve spend. Interacted people is the number that decides the shape of the whole programme, and discovering it late forces redesign.
Demo the thing a standalone platform cannot do: a journey that starts from a Dataverse record change — case resolved, opportunity won — with no connector in between. That is the argument, not the email designer.
Push back on "we'll keep HubSpot for now and decide later". Later never arrives, and the interim integration becomes permanent.
Before go-live, agree in writing which system owns unsubscribe and what happens when a contact opts out in the other one.
Tell the client that sending reputation is domain-level. If they are moving off an incumbent ESP, the warm-up plan is part of the project, not an afterthought.

Worth revisiting when the entitlement numbers or add-on tiers change, or if Microsoft alters how sandbox sends draw on tenant quota.