Who to hire for ExactTarget on Salesforce

Most requests to hire an ExactTarget partner arrive with the wrong shape. They ask for a "Salesforce partner", which usually means somebody who knows Sales Cloud and Service Cloud, and they describe a problem that lives somewhere else entirely: a send that landed in spam, a journey that stalled at a decision split, a data extension nobody trusts. ExactTarget was folded into Marketing Cloud, and the product you actually run is Marketing Cloud Engagement. The people who are good at it have a quite different working life from a core-platform consultant. They spend their days in sender profiles, SQL queries, AMPscript and the quirks of a send log.

This page is for the person writing the brief. It sets out what the work is, which credentials line up with it, how to scope a first piece of work, where hiring goes wrong for this product in particular, and ten questions that separate somebody who has done the work from somebody who has read about it. It ranks nobody, and it does not tell you what to pay. For the price of a project, see ExactTarget implementation cost.

#What the work really is

Salesforce's rebrand record puts the product lines together plainly: "Email Studio, Mobile Messaging, Journey Builder, and legacy ExactTarget features were all consolidated under Marketing Cloud Engagement." That sentence is useful to a buyer because it tells you where the skills sit. Email Studio, Mobile Messaging and Journey Builder share one account structure, one set of subscriber and contact data, and one set of permissions. A partner who is only strong in one of them will still be touching all three.

In practice a partner's hours on Engagement fall into a handful of packages.

Sending health. Sender authentication, the sending domain, IP reputation, list hygiene and suppression logic. When open rates fall off a cliff, this is where the answer almost always lives, and it is dull work done with care. A consultant who proposes redesigning your templates before checking authentication has told you something.

Data design. Data extensions, sendable relationships, the subscriber key, and Contact Builder. Many long-running ExactTarget accounts carry a decade of data extensions with overlapping purposes. Cleaning that up is slow, risky work, because a send somewhere is probably reading the thing you want to delete.

Automation. Automation Studio activities, SQL query activities, imports and file transfers. A good practitioner writes SQL that you could read aloud to the marketer who owns it, and documents what every automation reads and writes.

Journeys. Journey Builder entry sources, decision splits, wait steps, goals and exit criteria, and the test regime around them. Journeys are where marketers make changes weekly, so governance matters as much as build quality.

Content. AMPscript, dynamic content and templates that survive inbox clients you did not test in.

Connection to the core org. Marketing Cloud Connect, which syncs core-platform records into Engagement, and the mapping of leads, contacts and campaign members. This is the one place where core-platform knowledge genuinely matters, and it is usually the weakest link in a generalist team.

Email Studio is a part of our Marketing Cloud Engagement product suite. If a firm cannot explain which of those packages it would own and which it would leave to your marketers, it is not yet ready to be hired.

#Credentials that match the work

Salesforce's credentials catalogue lists four Engagement credentials. The names below are the ones shown on Trailhead's credentials pages when we checked; confirm the current names before you put one in a request for proposal, because Salesforce renames them from time to time.

The last row is the trap. Account Engagement used to be called Pardot and is a separate product. A team full of Account Engagement credentials is a fine team for B2B lead scoring and a poor one for a subscriber-based send programme. Ask for the credential names, then ask what each person has built in Engagement, in their own words.

Salesforce also publishes a B2C Solution Architect credential. It is relevant if your Engagement work touches commerce, loyalty or several clouds at once, because it speaks to how the pieces fit rather than how one tool works.

#A first engagement worth buying

The pattern that tends to work is small and diagnostic. Pick one business unit, ideally the one that sends the most, and ask for a two-part first engagement.

The first part is a health check lasting a few weeks. The partner reads your sender authentication, your sending reputation, your active automations and your journeys, and produces a plain list: what is running, what is dead, what is risky. The deliverable is a document a marketer can read, plus a list of ten or fewer things to change, in priority order.

The second part is one journey, rebuilt or built new, with real entry criteria, tested seeds, a defined exit and a runbook. The point is to see how the partner works when it matters: how they test, who signs off, and what they leave behind.

Put both parts in one statement of work with a decision point between them. If the health check is thin, you stop. If it is good, you carry on with the same people. You have spent a small amount to learn how they work in your account, rather than a large amount to learn it too late.

Do not start with a migration programme. The cited packaging sentence is clear that Email Studio, Mobile Messaging and Journey Builder are consolidated under Engagement. Nothing in it requires you to move your account anywhere, and Salesforce's pricing page describes the route for existing customers: "You can access the new next-gen Marketing Cloud capabilities, such as Agentforce, by renewing to a “+” edition of your current product." Whether you want those newer capabilities is a separate decision, and it belongs after the health check, not before it.

#Red flags specific to this product

A few things reliably go wrong when a generalist is hired for Engagement.

They treat it as a core-org project. You will hear about sandboxes, change sets and permission sets, none of which apply to a Marketing Cloud account in the way they apply to a core org. Ask them how they handle deployment between business units. A good answer involves packaging and careful manual steps, and an honest admission that it is awkward.

They propose a new account. A fresh account has no sending reputation, so every send starts from scratch and your first campaigns hit spam. Reputation is an asset, and a plan that discards it needs a very good reason.

They ignore subscriber consent. Suppression lists, publication lists and preference data are legal as much as technical. In Australia the Spam Act matters. A partner who cannot tell you where unsubscribes are stored does not understand the data they would be moving.

They quote a rebuild before reading a single automation. Ask what they have inspected. If the answer is a screenshot, the quote is a guess.

They promise to "modernise" journeys. Journeys are live. Somebody's welcome series runs every day. Modernise has a cost in missed sends, so ask for a cutover plan with a rollback.

#Ten questions for the first call

1. Which business unit structure do you assume, and why do you think ours suits it?
2. How would you check our sender authentication and sending domain in the first week?
3. Show us a SQL query activity you wrote and explain what it reads and writes.
4. How do you decide between a data extension and an attribute set on a contact?
5. What is the subscriber key in our account, and what happens if it is wrong?
6. Walk us through how you test a journey before activation, including seed lists and decision splits.
7. How do you deploy changes between business units, and what is manual?
8. How would Marketing Cloud Connect map our leads and contacts, and what breaks if the mapping is wrong?
9. What would you leave in Engagement even if we later adopt newer Marketing Cloud capabilities?
10. Who on your team has actually fixed a deliverability problem, and what was the cause?

Listen for specifics. A person who has done the work answers number five with a story. A person who has read about it recites a definition.

#Checking references without relying on logos

A logo slide proves that a firm once did something for that organisation. It does not say which person did it, whether they are still employed, or whether the account behaved well afterwards. Better evidence is available.

Ask to speak to the marketer who ran sends after the project, not the project sponsor. Ask what broke in the first month. Ask whether sending reputation held through the change. Ask whether the documentation was ever opened again.

Ask for a redacted automation inventory or journey runbook from a previous engagement. Marketing Cloud work leaves artefacts, and a practitioner who cannot produce an example has either not documented anything or has not worked on live accounts.

Ask the named consultant to share their screen and explain one of your own automations for ten minutes, unprepared. This is a fair test and it costs you nothing.

Finally, check credentials on the candidate's own Trailhead profile, and ask for the date. A credential from many years ago on a product that has changed a lot is only a start.

#Contracts and the statement of work

Three commercial shapes are common for this work. A fixed fee suits the health check and a single journey, because the scope is bounded and the deliverables are documents and a tested build. A capped time-and-materials arrangement suits data clean-up, where the volume of surprises is unknown. A retainer suits ongoing journey changes, where a marketer needs an hour of a developer's time each week.

Whichever you choose, put these in the statement of work: the business units in scope, the named consultants, the deliverables as documents or objects you can inspect, the testing you expect, a handover with a recorded walkthrough, and an explicit exclusion for anything outside Engagement, including Account Engagement and the core org unless you have named them. Specify who holds credentials and who can log in. Write a rollback clause for any live journey. Agree what happens to sending reputation if a domain or IP changes.

For the licence side, a partner should not be quoting your Marketing Cloud fees. Those are set by Salesforce; the relevant page is the ExactTarget licence page, and the commercial history is on what happened to ExactTarget.

#When you can skip a partner

You do not always need one. If a marketer already runs clean sends, can read your automations and owns the data, then a new template, a single send or one small automation is internal work. If your question is whether to move at all, read should I migrate from ExactTarget first. If the work is mostly connecting Engagement to the core org, the partner you want is a connector specialist, covered in integrating ExactTarget with Salesforce. Salesforce's own product page for the sending side is at Salesforce Marketing Cloud email.

Hire when the work is wide, risky or recurring: a deliverability problem, a rebuild of data design, a stack of journeys that nobody dares touch. Then use the questions above, buy the small first engagement, and let the evidence decide whether you carry on.