BCG Event Services

An early-stage service, one person, and a firm that ran on paper. A redesigned operation that took event apps from 12 a year to 216, and a journey map that showed where the rest of the team's services needed the same work.

Company

The Boston Consulting Group

Associate

Role

IT, event planners, service leads, business managers, operational innovation team

Team

Global

Markets

Service design • Operations design • Vendor evaluation • Customer journey • Web & content design

Scope

18x

Adoption of event apps –– from 12 to 216 events per year

6x

Throughput per team member –– headcount grew from 1 → 3

2.5x

Adoption in year one –– redesigned service experience, delivered solo on the original platform

01 – IMPACT

Productized a mobile app service and grew event app adoption from 12 events a year to 216, moving a paper-based meeting culture to digital, on 3x the headcount.

Role

Sole owner of the mobile app service, end to end — intake, process, delivery, and platform requirements. Team grew 1 → 3 as volume did; I trained and onboarded both hires.

Success of the mobile app service expanded my scope to assess and recommend improvements for the whole ecosystem of event planning services.

02 – SETUP

I was hired onto BCG's events team to take ownership of a service that IT had built and was still figuring out. The events team was transforming into a center of excellence within the company to support event planners firm-wide, and I owned the mobile app service within the digital portfolio.

What I inherited was a very early form of the service with enterprise-level expectations:

1

2

3

A FRAGMENTED EXPERIENCE

  • Unclear task ownership and expectations between us as service providers and our internal clients (meeting planners)

  • Undefined timelines and standards

  • Rough process and client materials

EVERY EVENT MEANT BUILDING AN APP FROM SCRATCH

  • The vendor built a separate app per event which meant a whole new workflow ensued once we received the build –– we passed each IPA file to IT → IT pushed it to the internal app store → we'd notify the planner and generate passwords for each attendee.

  • Logins failed constantly.Every attendee got a unique password, generated per event and emailed out one by one. New app, new credential, every time.

  • Files arrived late or broke on upload. Events don't move — and the fix sat with the vendor, on their timeline. I owned the outcome and held none of the levers.

  • No tracking, no view across concurrent events. Requests came in as emails to a shared inbox.

ONE PERSON, EVERY EVENT, AT THE SAME TIME

  • No handoff, no backup, no cover. Every request, escalation and launch ran through me.

  • Concurrent events at different build stages, tracked in my head, excel, and my inbox.

  • Internal customers with high expectations and no visibility into the queue — every request felt like the only one.

03 – PROCESS

EVENT APP PRODUCTIZATION

Part 1: I learned the operation from the inside before changing anything

Part 2: Made delivery repeatable and productized a bespoke service

Part 3: Evaluated vendors to change the platform

EXPANDED SCOPE

Off the back of the success with the system I built for event apps, I moved from optimizing one service to looking at the whole ecosystem.

This meant leading a customer journey mapping exercise with the operational innovation team, which produced a set of recommendations across the team's services.

I got into the CMS and taught myself how the technology actually worked, rather than relying on IT to translate. That meant I could tell the difference between a vendor limitation and a process problem.

Isolated planning resources

No single destination and no version control.

Misunderstood service offering

Planners genuinely didn't understand what the events team offered or how to use all services

No shared data layer, no single front door – each handoff started from zero

A planner using logistics support, the registration site and the mobile app answered the same questions three times, to three sub-teams.

+25%

New users, sustained beyond launch month

2x

Time on site and pages per session

87%

Task success in pre-launch testing

52% → 83%

Open rate jump

It surfaced three things:

From the journey map, I owned redesigning the website and the newsletter — the positioning and packaging opportunities. Planners then knew what existed, when to use it, and what it would cost them in time.

The website went from a place planners didn't use to the team's front door

One destination for announcements, resources and requests. Testing hit 87% task success, and the failures pointed at one thing: nobody could find a support article, because "Help Center" meant nothing to planners as a category. I renamed it Tools & Resources and embedded support links in context on each service page before launch.

We sent the newsletter less frequently, and they read more

Updating the content of the newsletter to venue recommendations, tips and ideas from peers, fixing the layout so it was faster to scan, and sending it quarterly made a massive difference in the open rate and popularity of the event team’s communications.

Replaced negotiation-per-instance with a scoped offering that has tiers, boundaries, and a predictable delivery path, plus repeatable, auto-generated timelines I created for each tier to speed up the intake process

  • Simple event = 4 weeks

  • Intermediate event = 6 weeks

  • Complex event = 8–12 weeks

Replaced e-mail intake with JIRA and eventually ServiceNow, which made demand evident.

Because I was the one delivering the service, conducting debriefs with planners, and working inside the CMS, I understood what the platform actually had to do; not from a requirements doc, but from years of hitting its limits. I defined those requirements, interviewed vendors alongside IT, and tested the products directly to inform the selection.

When implementing the new solution, DoubleDutch, I defined the information architecture for each event and advised planners on engagement best practices to drive attendee adoption.

1

2

3

  • I got into the CMS and taught myself how the technology actually worked, rather than relying on IT to translate. That meant I could tell the difference between a vendor limitation and a process problem –– which turned out to matter later.

  • Description text goes here

  • Description text goes here

04 – CLOSE

I inherited an early-stage service and left one the firm had adopted — 12 event apps a year to 216, in a culture that ran on paper — then took the same user-centric approach to the rest of what the team offered, moving the positioning and packaging of services forward.

IF I DID IT AGAIN TODAY

Recognize the platform limitations and initiate the change. I saw a service problem where there was also a vendor problem. I optimized around the platform's limits for a long time, and the process changes kept working — which is why I didn't question the technology underneath them. Success at the service layer masked the constraint below it. I defined the requirements and helped evaluate vendors when the change came.

Ask and understand what stakeholders are truly after. When stakeholders pushed back, I brought more data and evidence instead of asking what they were actually after –– the outcome they were trying to achieve, the why behind their proposed solution. Now I ask and understand first, then either implement it or come back with what I tried and why it shouldn't ship.