Dispatch queues, guest complaints, and paper trails — eliminated with Salesforce in 14 weeks

We spent the first two weeks not touching Salesforce at all. Instead, we ran structured process-mapping workshops with dispatch, guest services, and front-desk leads — separately, then together. The separation matters: combined workshops produce the version of the process that people wish existed, not the one that actually runs. Running them separately surfaces the informal workarounds that always carry the highest fix-value.

We documented 38 distinct workflows across fleet dispatch, guest request handling, escalation management, and cross-property reporting. Of those, 14 were manual processes that had no Salesforce equivalent and needed custom object or Flow design. The remaining 24 mapped cleanly onto native Salesforce Service Cloud capabilities. The output of Phase 01 was a two-page architecture blueprint and a prioritised build backlog — both reviewed and signed off by the client's ops director before Phase 02 began.

Phase 02 was a three-week build sprint focused on the Salesforce core: case object configuration for both transport and hospitality record types, custom fields for fleet assignment data, a unified queue structure that routed cases to the right team based on property, case type, and SLA tier, and Salesforce Flow automation for the 14 custom workflows identified in discovery. We used the same Salesforce org the client had purchased eight months earlier — it just needed a clean slate and a proper object model.

The key architectural decision was a single case object with two record types — Transport Case and Guest Services Case — rather than separate objects. This meant cross-functional cases (a guest with both a room issue and a transport complaint) lived in one record with one owner and one resolution timestamp, rather than two disconnected tickets. That single decision was responsible for the 3× improvement in cross-functional case resolution time.

The client's transportation management system had no native Salesforce connector. Their property management system (Cloudbeds) had a published API but had never been connected to a CRM. We used Celigo to build bi-directional data flows between both systems and Salesforce, with field-level mapping documented for every object. The TMS integration brought live driver availability, assignment status, and route data into Salesforce — meaning dispatchers could see real-time fleet status in the same interface they used to manage cases. The Cloudbeds integration pulled guest reservation data, check-in status, and special requests into the guest's Salesforce contact record automatically at the point of booking.

The integration took 12 days of development and 4 days of UAT — within budget and within timeline. The most time-consuming element was mapping the TMS's non-standard driver status codes to Salesforce field picklists, which required direct coordination with the TMS vendor's support team to obtain the current field schema. We've done enough integrations to know to request that documentation in Week 1, not Week 6.

With guest data now flowing from Cloudbeds into Salesforce, we connected Marketing Cloud to build the automated communication layer the client had never had. We designed three sequence tracks: pre-arrival (triggered 48 hours before check-in, including transport confirmation and property information), in-stay (triggered on check-in, with a mid-stay feedback SMS at the 24-hour mark), and post-stay (triggered 2 hours after checkout with a CSAT survey that fed directly into the Salesforce contact record). All three tracks were built in Marketing Cloud Journey Builder with Salesforce data extensions pulling directly from the PMS sync.

The pre-arrival sequence alone eliminated 40% of front-desk "where's my ride?" calls within the first two weeks of operation. The CSAT survey integration was the piece the client valued most in the post-launch retrospective — for the first time, guest satisfaction data was quantitative and attached to an individual guest record, rather than a periodic review of TripAdvisor comments.

The Monday morning Excel report was the first thing the ops director wanted to kill. We built a live Salesforce operations dashboard with four views: a GM overview (SLA compliance by property, CSAT by week, open case aging), a dispatch manager view (fleet status, active assignments, SLA countdown timers), a guest services view (open case queue, escalation flags, agent workload), and an executive trend view (30/60/90-day performance vs. targets). All four views pull from live Salesforce data with zero manual assembly. The ops director now reviews the dashboard at 8am daily rather than spending Mondays rebuilding it.

Training ran over four weeks with role-segmented paths: dispatchers, guest services agents, front desk, and managers each had a separate training track matched to their Salesforce permission set. We embedded Salesforce Trailhead modules for ongoing reference and ran a "floor walk" model where a Twopir team member was available on-site and via Slack for the first two weeks of live operations. Zero critical issues were raised in the first 30 days of production use.