
Mobility messaging at scale
Continuous Marketing Cloud ops since 2015
Uber
Continuous since 2015 · ExactTarget → Marketing Cloud
Continuous engagement since 2015 across the full Salesforce Marketing Cloud stack: Triggered Sends, Journey Builder, MobilePush, email, Preference Center, and the journey families that keep rider and driver messaging reliable under load.
Situation
Where the work sat
Since 2015, Red Hibbert has stayed on Uber-class Marketing Cloud work as a continuous engagement, not a discrete project wave. Ride-hailing turned email, push, and preference logic into infrastructure: a rider who requests a trip expects confirmation, a receipt that matches the fare, and lifecycle messaging that respects real trip state. Drivers need onboarding and operational messaging that does not fall over when volume spikes.
ExactTarget (later Salesforce Marketing Cloud) carried that graph: Triggered Sends for high-volume transactional rails, Journey Builder for multi-step lifecycle, MobilePush beside email, Automation Studio for the jobs underneath, and Preference Center so subscription and channel truth stayed usable as the product shipped every week.
What was broken
Why it was hard
Mobility messaging fails in boring, expensive ways. A trip receipt that lands late erodes trust. A payment or receipt path that double-sends creates support tickets. A rider onboarding series that ignores trip state feels broken. A re-engagement push that ignores preferences burns reputation. Safety and trust touches that fire on the wrong contact key become a brand problem, not a creative one.
Generalist contractors can ship a welcome journey. They rarely own deliverability at transactional volume, Preference Center edge cases, MobilePush and email as one contact truth, or the midnight queue when an event payload changes shape overnight. Continuous engagement needs a Cell large enough to hold that surface without rotating institutional memory every quarter.
What the Cell did
How we approached it
The Cell treated Uber as one continuous operating surface across the full SFMC stack. Named journey families stayed concrete: rider onboarding and welcome paths, trip receipts and post-trip transactional sends, payment and receipt messaging, rider re-engagement and reactivation, safety and trust messaging, driver onboarding and activation, and delivery / Uber Eats lifecycle where those lines of business shared the same CRM rails. Preference Center was in scope, not a side project: channel and subscription truth had to stay aligned with Journey Builder, Triggered Sends, and MobilePush.
Practically that meant specialists who write AMPscript and SSJS sitting next to people who own triggered-send semantics, Journey Builder decisioning, Automation Studio failure modes, and preference logic. The engagement has always run with more than nine specialists on the work, a Cell larger than nine so queue depth, email engineering, and journey ops did not collapse into one hero on call.
As Salesforce pushed Journey Builder deeper into the product, the Cell evolved with the platform: migrate fragile classic automations into clearer journey shapes where it helped, keep high-volume transactional rails where journeys would only add latency, and keep Preference Center and contact-key assumptions documented so product changes did not silently break receipts or push.
Week to week
How it ran
Week to week looked like continuous ops, not a quarterly SI sprint. Intake for product-driven message changes across email and MobilePush. QA against real event samples for trip receipt, payment, and onboarding paths. Preference Center and suppression checks before lifecycle launches. Send monitoring after releases. Deliverability hygiene when volume spiked. A named path when a journey or triggered send misfired after hours.
Cadence mattered: freeze windows around major product launches, paired review on anything touching receipts or payment-adjacent copy, and a shared runbook for “event arrived / message did not.” Specialists stayed on the stack long enough to remember which Automation Studio activity was load-bearing and which data extension was a landmine. Continuity since 2015 is the point: the same class of Cell kept owning the rails while ExactTarget became Marketing Cloud and the product kept shipping.
Outcome
What stuck
What stuck was continuous ownership suited to mobility: transactional, lifecycle, push, and preference messaging owned by a Cell larger than nine, not a rotating cast that rediscovers the contact model every quarter. Institutional knowledge stayed in the unit across the ExactTarget-to-Marketing Cloud years while rider onboarding, trip receipts, payment messaging, re-engagement, driver onboarding, and Preference Center work kept shipping.
Why it still matters
What buyers should take
Every high-volume consumer brand eventually learns that “campaign ops” and “transactional reliability” are different jobs. Buyers still hire body shops for the first and wonder why receipts break or Preference Center drifts. This continuous engagement since 2015 is the template for Cell Ops on stacks where silence after a send failure is unacceptable.
Next step


