Services

Connect your marketing stack without replacing it.

Connect your ESP, CRM, website events, customer profiles, consent data and decision logic into the EngageMKTG platform. Start with one bounded application, test its data and eligibility rules, and keep channel execution in the systems your team already operates.

Updated

Start an implementation review

Who this is for

Lifecycle teams whose records disagree. A CRM may call someone a customer while an ESP records them as unsubscribed and a website event belongs to another identifier. Implementation begins by making those meanings explicit. A new automation cannot resolve a conflict that nobody has defined.

Operations teams maintaining brittle exports. Repeated spreadsheet transfers can leave consent, timezone, suppression and lifecycle fields out of sync. Map the source of each decision input and the event that changes it. The aim is a reviewed connection between systems, rather than another hidden copy of an audience.

Teams piloting a new decision flow. You may want to apply Day-Zero Activation, Campaign Error Shield, dormant-list revival or a custom planner without replacing the rest of the stack. Choose the first use case, the evidence needed to assess it and the person who owns its stop or expansion decision.

What you get

Implementation connects a source inventory, implementation map, profile and event schemas, status mapping, decision flow, pilot launch and QA report. The table below connects those deliverables to the decisions they support. It does not imply that an unreviewed integration is already available in your account.

Scroll for more →

Deliverable Format When
Source inventory and implementation map System, field and responsibility map Discovery
Profile unification Reviewed identity and profile schema Mapping
Consent layer Permission and suppression mapping Mapping and validation
Event mapping Event families, identifiers and timestamps Mapping
Status fields Current marketing state and transition rules Mapping and tests
Planner configuration Inputs, constraints, decision flow and reasons Configuration and tests
Reporting Pilot baseline, output checks and QA report Test and pilot read-out

Delivery formats and the first-implementation schedule are agreed during discovery; the sequence below is a set of milestones rather than a fixed delivery promise. The useful output is a map your team can inspect and a pilot whose behavior can be checked. Simply connecting an API does not prove that identities, permissions or reporting are correct.

How it works

  1. Discovery: identify the first decision. Inventory sources and choose the application to implement. Describe the current workflow, known gaps, available records and the outcome you want to measure. Keep the scope narrow enough that a pilot can distinguish a working decision path from a collection of connected tools.
  2. Mapping: define shared meanings. Review identity resolution, event families, timestamps, current marketing status, consent and suppression. Decide which source is authoritative when records conflict. A subscription for one brand should not silently become permission for another brand.
  3. Connection: prepare the execution path. Connect the agreed ESP, CRM or API interfaces and map the fields required by the planner. Keep the existing system's channel role clear. The decision layer needs to know whether an output is a recommendation, a queued action or an execution request.
  4. Testing: exercise the exceptions. Check missing identifiers, duplicate events, stale status, incomplete consent, unsubscribed records and frequency limits as well as the happy path. Validate outputs and reporting before exposing a larger audience to the new flow.
  5. Pilot: measure one bounded application. Launch the agreed use case with a baseline and explicit review points. Inspect the reasons behind selections and suppressions. Expand only when the data, operational behavior and reporting support that decision.

No fixed duration for a first implementation is currently published. Discovery, mapping, testing and pilot are milestones, not invented week numbers. The 72-hour audit and 30-day revival stream described elsewhere are separate offers; they should not be relabeled as a general implementation timetable.

Works alongside your current tools

The audit form recognizes Klaviyo, Mailchimp, HubSpot, Salesforce Marketing Cloud, Braze, Iterable, ActiveCampaign, Ghost, beehiiv, Substack and other platforms. These are scoping inputs, not a claim that every feature has a prebuilt connector. Identify the actual account, available interfaces and required direction of data movement during discovery.

Keep the ESP responsible for the sending functions you already use. Keep the CRM's role explicit. Website behavior should enter the timeline with enough identity and timing context to support the selected use case. Changes to billing, permissions or platform accounts are not an automatic consequence of choosing an implementation review.

What it costs

Scoped after a discovery call. Scope depends on list size, the number of ESPs, the number of brands and the data contracts and pilot being connected. Agree the initial implementation boundary, responsibilities and acceptance checks before work begins.

What we don't do

Implementation is not a reason to replace a working ESP or CRM by default. We do not infer missing consent, overwrite suppressions to make a test pass or treat every profile as sendable. Planner configuration does not create a guaranteed revenue result. A pilot should leave your team able to explain what happened, which records were excluded and which remaining gaps prevent expansion.

FAQ

Do we migrate off Klaviyo or Mailchimp?

The published approach connects your existing tools without requiring a full migration. Channel execution can remain in the ESP while EngageMKTG supplies reviewed customer context and decision logic. Any proposed replacement needs a separate reason and scope.

What data do you need?

Begin with the source inventory, identifiers, profile fields, relevant events, status, consent and suppression records required for the first use case. The implementation map should name the source and owner for each input. More data is not automatically more useful.

How long does a first implementation take?

No fixed first-implementation duration is published. Agree the discovery, mapping, test and pilot milestones after reviewing the systems and evidence. A missing dependency should change the plan rather than become an unsupported delivery promise.

Who owns the data?

Connecting the systems does not itself define or transfer ownership. Confirm rights, permitted use, export and responsibilities in the applicable scope and agreements. Operational access and legal ownership should not be treated as the same thing.

Record the gap and determine which use cases can proceed without inferring permission. Missing consent should prevent a marketing action that requires it. The pilot must preserve existing opt-outs and suppression rules.

How do we know the pilot works?

Review the mapped inputs, decision reasons, selected or suppressed outputs and reporting against the agreed baseline. A successful connection is only one layer of evidence. Business impact still needs measurement on the defined pilot cohort.

Read before you buy