Marketing Cloud Engagement Implementation for Freight

The contact key is chosen in the first week of a Marketing Cloud Engagement build and it is the decision that quietly settles what the platform can ever do for you. A freight forwarder we took over had used email address, which meant the four dispatchers sharing one planning inbox at a 3PL customer were a single subscriber, and 11 percent of a quote follow-up send reached somebody who had never seen the quote. Changing it afterwards meant rebuilding every data extension relationship and reprocessing eighteen months of send history. We decide the key against your TMS customer identifier before anything is built, and we put the reasoning in writing. The data model in Contact Builder: Attribute groups that mirror how freight is actually sold: account, site, lane, shipment, and the person, who moves between all of them and often changes employer twice a year. Sendable data extensions keyed on the identifier your TMS owns, not on an address someone typed into a form. Relationships in Data Designer defined once, documented, and never patched by adding another flat extension because a campaign was due on Thursday. Retention policies set per extension at the point of creation, because retrofitting them onto a populated extension is not a thing you get to do. What we automate, and what we refuse to: Automation Studio jobs triggered by file drop on SFTP from Transporeon, Trans.eu or your own TMS export, SQL query activities that resolve the day's shipments into segmentable states, import activities where update against overwrite behaviour is specified per column. Journeys built on API entry events for the moments that carry money: quote issued with no booking after 72 hours, carrier insurance certificate expiring inside 30 days, contract anniversary approaching, a lane whose volume has fallen against its own trailing average. We will not build a journey whose exit criteria nobody in your business can state out loud, and we will not build twenty when four carry the volume. Sending reputation: Sender Authentication Package, SPF, DKIM and a DMARC policy you actually move from monitoring to enforcement rather than leaving at p=none forever. Dedicated IP warmed over four to six weeks against a real send calendar, which means the launch date depends on your content being ready, not on ours. Reply Mail Management configured, because in this sector out of office replies and bounced dispatcher addresses are the fastest signal that an account has reorganised. Erasure, retention and the awkward timings: Contact deletion in Marketing Cloud is a queued process, not a click, and it does not finish the same day. We build the request path, the suppression that holds in the meantime, and the log your data protection officer can show a regulator, in Polish or English. Anyone who tells you erasure is instantaneous here has not run one. Not included: Copywriting, email design, template production beyond the structural build, media buying, and Marketing Cloud Personalization, which is a different discipline and we would rather name someone who does it properly than pretend. Who should look elsewhere: Organisations sending under roughly 50,000 emails a month, where this platform is an expensive way to do what a smaller tool does better. Teams whose Sales Cloud data is not trusted internally, since Marketing Cloud Connect will faithfully propagate that mistrust. Instances where an incumbent partner still holds production deployment rights and is staying, because two hands on the same instance is how journeys get published twice. How it runs: Discovery with your TMS owner and campaign lead, then the model, then build, then a supervised send window where we sit with your team through the first live journeys. Handover is the data dictionary, the journey specifications with entry and exit criteria, and the SQL with comments. Your admin, your instance, throughout.