Salesforce Marketing Cloud Implementation, Data Model First

Marketing Cloud bills on contact count, and contacts do not leave when you remove them from a data extension. Contact Delete is a queued, asynchronous process that can take days to finish on a large account, and the record counts against you until it does. The accounts we inherit routinely carry 30 to 60 percent contacts that no journey has touched in a year. That is the first thing we measure, because it changes what the platform costs you before it changes anything else. The order: Contact Builder before anything. The contact model, the attribute sets, and the decision about what is a contact versus a related record. Subscriber key policy is the one decision in this platform you genuinely cannot change later without a rebuild, so it gets its own session, its own document and a sign-off from whoever owns the CRM. We have declined engagements where the client wanted to start with email templates. Data extensions, not lists. Sendable data extensions with a defined relationship to the contact model, populated by query activities on a schedule you can reason about. Lists are a legacy convenience that stop scaling at exactly the point you need them to. Marketing Cloud Connect gets scoped explicitly: which objects synchronise from Sales Cloud, at what interval, and which system is authoritative for each field. Synchronised data extensions where the volume justifies them. The failure mode here is a bidirectional assumption nobody wrote down, discovered when a sales-owned field starts overwriting a marketing-owned one. Automation Studio carries the scheduled work, with error handling that alerts rather than logs. A query activity failing quietly does not stop a journey, it starves the entry source, and the symptom is a campaign that sends to nobody for a week while the dashboard looks fine. Journey Builder: entry sources, re-entry rules, goal and exit criteria decided before the journey is built rather than retrofitted. A running journey version cannot be edited, so the versioning strategy is part of the design rather than something discovered at the first change request. AMPscript and SSJS only where dynamic content genuinely cannot do the job, kept in a snippet library instead of scattered through email bodies where the next person will not find them. Deliverability: Sender Authentication Package configured properly, DMARC alignment checked against your existing records, and an honest conversation about whether a dedicated IP is warranted at all. Below roughly 250,000 sends a month it usually is not, and a cold dedicated IP will hurt you. Where one is warranted we warm it over four to six weeks against a documented volume ramp, starting with your most engaged segment, and we do not compress that schedule because a campaign date moved. We decline: Engagement implementations for teams whose real requirement is Account Engagement or HubSpot. We say so before contract and we lose those deals. The platform is priced and staffed for a scale of operation, and running it below that scale means paying for complexity you will never use. We do not produce email design or creative. We do not implement Personalization or Mobile Studio SMS programmes inside this scope; SMS carries its own consent and carrier obligations and deserves separate scoping. Not for: Teams without a dedicated Marketing Cloud operator, or a plan to hire one during the engagement. This platform does not run itself and hands over badly to a generalist. Also not for anyone who needs a first send inside four weeks. The contact model takes longer than that, and doing it in the wrong order is the expensive mistake we are here to prevent.