Migrating our telephony platform to a CCaaS.

What is a CCaaS?

Contact Center as a Service (CCaaS) is a software deployment model that enables companies to achieve personalized customer experiences, and real-time omnichannel communication, whilst improving agent management, productivity and efficiency.

In amaysim, we are open to different technologies and software that will help us achieve our technology goal: continuous delivery. This means we are pretty agile when it comes to welcoming, embracing, and letting go of different platforms, keeping our goals and values aligned.

Let’s talk about our contact centre, where most of the big love happens through the amazing work of our business champs— the Customer Service Centre team.

For our customer service team to be champs, the amaysim technology team, especially the Platforms & Operations team, need to ensure that the platforms we use are well supported, maintained, and managed.

Let’s step back a bit…

Before State

In amaysim, we used a legacy platform for some time before we migrated to our current CCaaS platform.

It initially worked really well. However, as our organisation grew— both organically but also through acquiring and expanding into different lines of business— our use cases and demands on our contact centre also levelled-up. This meant we also needed to power up.

We were faced with platform limitations, and the answer to our guiding questions became a bit blurry:

Are we confident that what we’re building is the right thing for our customers? If not, how do we ensure that we minimise waste and can learn and pivot quickly as needed?

Are we confident we can release many, many times a day, at any time of the day or week?

Are we confident that if something does break, we’ll know about it first and can resolve it before most of our customers even realise it?

So we built a business case, formed an A-team across different teams, and invested in a platform (and people) that has allowed us to grow and importantly keep being amaysim to our amazing customers through our telephony platform.

What we can’t measure, we can’t improve.

We were driven to deliver the best possible solution that enabled amaysim to:

  • to own and fully manage the telephony platform (giving us maximum control and flexibility);

  • increase productivity, efficiency, and lower costs;

  • deploy changes whenever we need to and rollback ASAP if needed;

  • integrate with different technology in an ecosystem;

  • create an omnichannel platform across all lines of businesses;

  • achieve personalised customer experience;

  • and improve contact centre reporting.

After State

After a requirements, consultation and initial vendor comparison exercise, we chose to start with a pilot on a small group in the business. This enabled us to undertake a trial migration from our old telephony platform to our chosen CCaaS (AmazonConnect).

This strategy worked well and allowed us to test and validate our choice of platform in a meaningful way. Starting with a small and manageable group validated and backed up our “re-platforming” initiative(s) and allowed us to answer some important questions:

  • How easy is this new platform to manage, configure, onboard, and offboard?

  • How many existing opportunities will this platform be able to solve for us?

  • How much (positive) impact will it give on the business and our customers?

It was quick and quiet work (minimal to zero disruptions) across the business— because it was a small group with a straightforward contact flow, the migration was a hit! It wasn’t a big deal (or so we thought?!), until other LOBs took notice, and began asking what needs to be done to migrate their line of businesses to the new platform!

We had 6 different lines of business at the time, so we’ve had different successful migration phases (and different projects) in a year! If that ain’t awesome to you, I don’t know what is?!

Our pilot migration and subsequent business-wide migration enabled some huge changes in how we allow our Customer Service team to work with and help our customers. It’s meant that we can keep giving back that extra love to our customers while we (the technology team) continue to support our champs (customer service centre), and more!

PS: And we don’t have any plans of stopping doing amazing things for our customers because let me remind you again…

Continuous Delivery, people!

Best practices

This may be a long list, but I promise they are worth considering!

1. Approach the migration from multiple perspectives.

To have a successful contact centre migration, we didn’t isolate it as a “technology delivery project”, but instead, we operated in a way where multiple perspectives were looked into. (Yes, that’s all stakeholders across the board.)

2. Put a migration strategy in place.

As part of the Platforms & Operations team, and having ownership of our telephony platform, I’ve adopted our internal business strategy and AWS’ migration strategy.

photo credit to Amazon Web Services

3. Do it in phases.

Familiar with the shiny object syndrome?

If not, it is a continual state of distraction brought on by an ongoing belief that there is something new worth pursuing.

Not because the new platform takes away all the pain in the contact centre, but it doesn’t mean we have to do it all at once!

We can do it in phases:

  • Phase 1: As-is migration.

  • Phase 2: Improvements based on phase 1 implementation data.

  • Phase 3: Beta and deploy new features available in the ecosystem.

  • Phase 4: repeat 2 & 3.

4. Communicate, communicate, communicate.

Nothing beats effective communication across all relevant people in the project. Giving updates wins, challenges, blockers, next steps, etc., is way better than nothing. Believe me, it saves a lot of time and energy (and tears)!

5. Document everything.

It doesn’t matter if it’s a small change— document everything! In a migration project, there may be different moving parts. You wouldn’t want to miss out on that little change that you didn’t know would have a huge impact later on. This includes migration checklists— before the go-live, on the go-live day, and post-migration optimisations.

6. Go back to basics! (probably the highlight of this blog 😉)

Basic, I meant technical foundation workstream. I also learned this from one of AWS’ training (and honed through multiple migrations we did). It consists of 5 phases:

  • Discovery and roadmap - usually part of the business project, but are also beneficial to keep up-to-date if you’re a platform owner and heavily involved in the configuration.

  • Design - never take for granted the importance of design documents. If values are a guiding principle in living our lives, design documents work like that in a migration project.

  • Build - guided by the design document. Factor the effort for setting up the relevant tools into the scope of the project; they will be beneficial in the long term.

  • Test - should always be a rule of thumb. My mantra is: no matter how seemingly small the change is or “no-brainer” it is, we need to test. There are 4 types of testing: (1) unit testing, (2) integration testing, (3) end-to-end testing, and (4) user acceptance testing.

  • Deploy - once the end-to-end testing is done, and user acceptance testing was fulfilled and successful, the platform must be ready to handle live traffic when user journeys are scheduled to go live.

  • Post-go-live support - the project team remains engaged with the business as usual (BAU) support teams and end-users during the first few weeks after the new contact centre goes live. This will also help in identifying what to include in the next phases of the migration through data and feedback.

7. Optimise, optimise, optimise.

There’s always room for improvement… and so is your contact centre in place. 😂

Conclusion

In amaysim, we continue to work on continuous deli— oh, did I mention that already? Okay, let me reframe that…

In amaysim, we continue to create the best customer experience possible, leveraging in the technologies we are shipping. 🚀

P.S.

Oh, how rude of me—

Hello, my name is Desiree Cantor-Lopena. I was an Operations Analyst for the PlatOps team, and am now a Business Analyst for the Projects & Delivery team in amaysim.

If you wish to connect with me, you can do so through LinkedIn.

P.P.S.

The views expressed in this article are mine alone and do not necessarily reflect the views of my employer, amaysim Australia Ltd.

Previous
Previous

Flutter test : mockito GenerateMocks vs GenerateNiceMocks

Next
Next

Using GitHub Actions to trigger Actions across repos