Case Study — Change Enablement
Guest CRM Pilot
Enabling a pilot group of hotel teams to adopt a new guest relationship management platform — not just navigate it, but understand why the workflows were changing.
- Organization
- IHG Hotels & Resorts
- Role
- Learning Strategist / Creative Producer
- Project type
- Platform pilot enablement
- Focus
- Change enablement, instructional design, multimedia production
- Status
- Evidence-supported case study
Project snapshot
Portfolio package
Full enablement package — cover, pilot storyboard, workflow, feedback, and delivered kit.
Executive summary
Adoption fails at the reasoning gap, not the interface.
A change enablement initiative that helped IHG's pilot hotel teams adopt a new Guest CRM platform with confidence, achieved by teaching the operational reasoning behind each workflow rather than the software's interface.
This wasn't a software rollout so much as a readiness effort: hotel teams needed to understand new expectations and how guest information would now support better service — not just where to click. Scalable enablement resources helped pilot participants navigate the change while surfacing the feedback that shaped the eventual enterprise release.
Business challenge
Technology adoption fails when people know where to click but not why it changed.
The pilot needed enablement that prepared employees for new workflows, reduced uncertainty during participation, and connected software actions to guest service outcomes — while also surfacing usability questions before broader rollout and producing communication assets that could be reused.
Opportunity
Why this was worth solving.
What became possible
- Support successful pilot participation
- Reduce onboarding friction
- Provide consistent enablement across participating hotels
- Create reusable learning resources
- Improve clarity around new Guest CRM workflows
- Support future enterprise deployment through pilot feedback
My role
Owning the enablement strategy through a moving target.
- Strategic ownership
- Owned the decision to organize enablement around hotel operational workflows rather than software menus, prioritizing operational reasoning over interface familiarity.
- Production accountability
- Accountable for storyboarding, recording, and editing tutorial video, motion graphics, and voiceover integration across the full deliverable set.
- System design
- Designed the Reference Guide, Access Checklist, Training Toolkit, and Pilot Diary as one modular, reusable system rather than four separate documents.
- Stakeholder partnership
- Partnered with product, operations, learning, and creative stakeholders through multiple review cycles covering workflow accuracy, terminology, and translation readiness.
- Accessibility & localization
- Built accessibility review and localization support into the production process from the outset.
Process
A structured pilot production cycle, refined across review rounds.
Stakeholder discovery
Identified how the new platform changed day-to-day operational tasks and guest interactions.
Workflow & learning architecture
Mapped new workflows and structured the learning approach around them rather than the software's menu structure.
Storyboarding & production
Built reference guides, storyboards, screen recordings, motion graphics, and voiceover into the toolkit.
Accessibility & stakeholder revision
Ran accessibility review alongside multiple stakeholder revision cycles refining terminology, workflow accuracy, and instructional sequencing.
Pilot delivery
Delivered the final enablement package — QA'd and translation-ready — to the pilot cohort.
Strategic design decisions
Design decisions built for a platform that was still changing.
Why organize around workflows instead of software menus?
Operational understanding was prioritized ahead of interface familiarity — the goal was confidence in the *why*, not memorization of the *where*. That confidence is what determines whether a pilot succeeds long before adoption gets measured.
Why annotated demonstrations over full screen recordings?
Progressive disclosure and annotated focus reduced cognitive load during a pilot where the interface itself was still evolving. Protecting attention protected the pilot's credibility with a workforce already absorbing a system change.
Why separate quick-reference from long-form instruction?
Pilot participants needed different resources at different moments — a checklist mid-shift, a deeper guide during onboarding. Matching resource to moment is what made the pilot self-sustaining without constant facilitator support.
Why design for revision from the start?
Because the pilot software was changing, every asset was built to be updated rather than treated as a finished, static deliverable. That decision protected the enablement investment from going stale before the pilot even concluded.
Deliverables
A modular enablement package built to evolve with the pilot.
Evidence available
What this work demonstrates.
A standardized pilot enablement package approved for use across all participating hotels.
A feedback-to-impact trail showing what pilot participants reported and how the toolkit changed in response.
Modular materials designed to be updated rather than remade as the platform evolved.
Coordinated input from product, operations, learning, and creative stakeholders across review cycles.
Quantitative business outcomes were not available for publication.
Reflection
What a pilot program actually demands of enablement design.
Pilot programs require adaptable learning assets — the platform was still changing while the materials were being built, and design decisions had to account for that instability rather than wait for a stable target.
Change enablement extends well beyond software instruction. Operational context, not interface familiarity, is what builds learner confidence, and stakeholder collaboration across product, operations, and learning teams is what keeps instructional content accurate as workflows shift.
Modular assets simplified every later revision — a lesson that shaped how enablement materials were structured on subsequent projects.
If I were doing this again
- Instrument the toolkit itself with simple usage tracking, so which resource pilot participants actually reached for becomes observable, not just reported anecdotally.
- Run a brief structured observation session on the hotel floor before finalizing workflows, to validate the operational sequencing against real shift conditions.
- Formalize the pilot-to-enterprise handoff as its own deliverable, so the scaling path is explicit rather than implied by the toolkit's modularity.