Tom Morgan: [00:00:00] Welcome to ACP, the Amazon Connect podcast. This is the show that focuses on Amazon Connect and related technologies. I'm your host, Tom Morgan. Introducing Episode 5. And I'm joined as usual by my co host, AWS Solution Architect, and Contact Center Consultant, Alex Baker. Find out more about Cloud Interact by visiting us at cloudinteract. io. 
 
Hello. Welcome to another episode of ACP. And we're here in the ACP studio in person with Alex. Alex, it's great to see  you again.
 

Alex Baker:  Hello again, Tom. Always good to  see you.

Tom Morgan: And yeah, lots and lots of things happening this week, I think. So we're going to kick off with our sort of news item section. Cause I know you've been, so you keep a good eye on what's been happening. 
 

So yeah, what's new in Amazon connect this  week?
 
 Alex Baker:  Yeah, I do. I feel like we've got the potential [00:01:00] for another sort of packed 20 to 30 minutes of material here. But yeah, the breaking news. Release notes type stuff. A couple that I want to talk about there. Amazon have added a bit more to the Amazon connect cases functionality. 
 
 

First of all we mentioned something a couple of podcasts ago about adding audit history to cases. Cases now provide some new historical metrics around cases, including things like average case resolution time. Average contacts per case, cases created, and then reopened or resolved, cases resolved on first contact, and current cases. 
 
 

These are available through some new reporting in the Connect Historical Metrics dashboard and should allow organizations to report on the, the sort of efficiency of their, their case management processes. The other one that looks quite cool, not directly connect and not sort of in the connect release notes, [00:02:00] but very much related. 
 
 

And that's the, the general availability of the Lex Q and a intent. And that is a built in Lex intent, which uses an Amazon bedrock foundational model to search and summarize FAQ responses using a customer's configured knowledge base. And this is cool because it allows you to be much less prescriptive when configuring your Lex bots. 
 
 

So previously you had to carefully define individual intents, whereas this should allow you to provide more generalized responses to FAQs just based on the data that you're exposing to it from the, the knowledge base that's connected. So  
 
 

Tom Morgan: that, if I understand that correctly, it's not, so you'll get, we're getting away from, you know, almost not quite keyword searching, but intent searching and matching up to an individual FAQ item. 
 
 

And this is more. Almost like a small language model, like build a language model around my FAQ so that when [00:03:00] customers ask things, even if it wasn't, even if there isn't an actual like FAQ question that lines up completely. With what they've asked it, I can still figure out what the answer  
 
 

Alex Baker: is. Yeah. And, and helps with, like you mentioned, not having to have those individual intents for sort of every single one of your FAQs that you might've wanted to answer previously. 
 
 

This should allow you to, to define the Q and a intent. And then it will, like you say, use a bit of smarts in the background to go and search for what it thinks is the best answer based on the information provided to it. Nice.  
 
 

Tom Morgan: Nice. That sounds good. That sounds really cool. Actually, I feel like that's going to be a bit of a game changer for kind of lots of people that are trying to get those common questions answered by bots before they get through to agents. 
 
 

Alex Baker: Definitely. It probably improves your, your speed to market with that kind of FAQ bot functionality as well.  
 
 

Tom Morgan: Yeah. And, and definitely the, the management reports as well for cases are kind of useful, I guess, if you're already using cases, more [00:04:00] reporting is always good. So, I think, yeah, being able to sort of see what's going on. 
 
 

Yeah, agreed. It's interesting, some of those, some of the reports as well, like, resolved on first contact, and they're, they're really actionable, useful reports, actually, aren't they? They're they're the kind of things that people care about. Definitely.  
 
 

Alex Baker: Yeah, yeah. First contact resolution, that kind of thing. 
 
 

Yeah, for sure. Nice, nice. So that's the things  
 
 

Tom Morgan: that are new. So let's get into our sort of scheduled topic around deployment and kind of in the show, in the show notes, like I put, I put like a line in, which was just, you know, so you want to have a contact center, you know, and we talked a couple of episodes ago. 
 
 

I think the first episode we talked just about how easy it is to set up Amazon Connect, right? And you could like click, click credit card done and you can have a contact center. I guess the reality is probably, and that might be fine, like that reality might well be true if you're very small but if you're of a decent size and or you already have a contact center, I guess there's a process, right? 
 
 

There's a, there's some best practices you should think about. There's some [00:05:00] stuff, there's some planning. So like, where do you start with that stuff? Yeah,  
 
 

Alex Baker: exactly. Where, where to start? And I think, first of all. Yeah, this is another one of those kind of ambitious topics for a relatively short podcast, right? 
 
 

And there's no one size fits all. We, we, we'd always take some time talking to our customers about the, the planning and the, the methodology. I think there's probably also a whole follow up episode around delivery methodology. Considerations around people around governance. And I think what we should do is arrange another episode with one or a couple of our delivery leads to, to go into, into that. 
 
 

Definitely. Whereas this episode, I suggest maybe we keep it a bit more towards the technical side of things. Yeah, that makes sense. Yeah, where, where to start. So you, you kind of, you mentioned maybe proofs of concept, which we've talked about in the past. Amazon connect is great for running POCs. 
 
 

You can prove the technology. You can allow [00:06:00] your staff to get hands on with it. And you can start to put together your business case and check whether the business case stacks up for, for proofs of concept and also for larger transformations, it's quite important to have a sense of your overall vision, what you want to achieve, have some desired outcomes and have some success criteria as well. 
 
 

So what, what does success look like during this transformation  
 
 

Tom Morgan: and should those be quite. Specific, like, should you write them down? Should you be like, you know, in some period of time, six months time, we want to be, you know, I don't know, whatever it is, converting this many calls within this amount of time or what should that look like? 
 
 

Alex Baker: Yeah, absolutely. I, I think it's, it's always good to have specific and, and. measurable goals, right? So and they over the course of a transformation, perhaps they, they might change, but keep a track of what your goals were to start with on any changes to them so that you can, you can measure that the success [00:07:00] later on down the line, you know, whether it is around. 
 
 

Things like first call resolution whether it's just a around, you know, a a need to exit from a legacy platform, for example. Oh  
 
 

Tom Morgan: yeah, of course. I didn't think about that. Like migrations or like, yeah, you, you're moving from somewhere, but, but you've got a time on that because of contract renewal, I guess, or end of life or something  
 
 

Alex Baker: like that. 
 
 

Definitely. And we've, we've seen that quite a bit where we've had a, a customer. Who has a real sort of upcoming exit date for a an existing platform. They. Need to, to hit that date and therefore you, your, your goals for, for migration and probably a bit different to someone who's focused more on the sort of the transformational aspect of what can the new technology bring us. 
 
 

It's, it's more of a, we have to do this. Therefore we'll keep it maybe as more of a, a minimum viable product approach to start with. Got it. Yep.  
 
 

Tom Morgan: That makes sense.  
 
 

Alex Baker: Anything else? Yeah, [00:08:00] loads of other points that I've noted down to, to have a chat about. So. What geographies are in are involved? Connect obviously is a global platform but are all of your agents and your customers and your phone numbers, are they all in one region? 
 
 

If so, it's probably an easier decision where to put your Amazon connect instance. Then if you have a sort of fully global presence, and if you are more global, you're going to need to take into account a whole load of variables, things like network latency, phone number availability, feature availability and cost, because those vary across the Amazon Connect regions that are available. 
 
 

You might find that the traditionally the U S East North Virginia region kind of gets everything as soon as it's released, whereas some of the other regions take a little while to catch up with the features.  
 
 

Tom Morgan: Right. So it's, it's also a case of, yeah, analyzing the features you want and making sure they're available everywhere and factoring that into your planning. 
 
 

Alex Baker: [00:09:00] Definitely. Yeah. And, and you'll find with some of our global customers. Again, it's, there's probably some compromise involved in this. You, you're maybe not going to have. A location for your connect instance that ticks every single box, you might have to cite it somewhere and have the best possible compromise of, you know, distance between agents and the instance or phone number availability. 
 
 

And it's that kind of thing that you do need to look at very carefully and make sure you plan for when you're, you're, you're doing your, you're running your planning stage  
 
 

Tom Morgan: and I guess also like. And every company is probably gonna be a little bit different. Like, do you have one global contact center or is the reality is that you have several different contact centers sited around the world and they all operate slightly differently with local customs and just how it works. 
 
 

And actually you could approach each one separately and migrate  
 
 

Alex Baker: separately. Yeah, another great consideration. Indeed, where you have sort of different global locations with different contact centers, maybe you do want to set them up [00:10:00] on separate instances, but I'd be considering before you make that decision, how closely might they work with one another? 
 
 

So are they quite disparate in nature and, you know, Germany doesn't work with the U. S. so much. If so, perhaps an instance in each region will work, but if they're working really closely together, they're transferring calls to one another. Perhaps you might want a more of a single instance approach. Got it. 
 
 

Yeah, that makes sense. What else have we got? It's worth thinking of the level of maturity and the cloud adoption strategy of the wider business. So if the, if the organization is new to cloud adoption. Do you need to consider things like your initial AWS account set up? Are you gonna, are you going to set up things like an AWS landing zone? 
 
 

So a sort of organization structure within your account, which allows you to scale and grow.  
 
 

Tom Morgan: So it's almost like pre work, like you're deploying into the cloud, but like, is your cloud [00:11:00] ready to receive you if you've never deployed anything to the cloud before? The answer might be no. So it's like there's that you might have some homework to do before you can even get started. 
 
 

Yeah,  
 
 

Alex Baker: definitely. And also, you know, sometimes within organizations, you might find that a department dealing with contact center deployments isn't the same department that deals with other other cloud deployments. And so it's good to get that. The holistic kind of view of, of how, what the organization wants to do in the cloud and how other parts of the organization do it. 
 
 

So you're not ending up with sort of two separate deployments and, and different cloud environments that are unrelated, but within the same business. Yeah, that's a  
 
 

Tom Morgan: really good point. Like telephony is often dealt with quite separately, right? And contact centers probably come out of telephony. So, yeah, absolutely. 
 
 

That that can be a  
 
 

challenge.  
 
 

Alex Baker: One other thing around the, that kind of level of cloud maturity. Are you going to be setting up connect sort of in its own standalone instance and deploying everything? Quite [00:12:00] manually or does the organization use infrastructure as code? So are you going to use code pipelines and have automated deployments between dev, test and production environments? 
 
 

Okay, yeah, that makes sense. Another one to consider around your general environment and a network setup, is that optimized for running connect? So that includes the, the hardware that the agents use. Are they the PCs that they use suitable? Do they have the right headsets? Can they, if possible, use a wired network connection rather than wireless? 
 
 

Do they use a VPN? Are you using a virtual desktop infrastructure? If you have agents in, say, South Africa and your connect instance is, is in the UK, how does that network latency look? There's quite a bit of, of careful checking of your, your environment just to make sure that it's going to support what it is that you want to stand up. 
 
 

Yeah,  
 
 

Tom Morgan: definitely. And I guess that's even more important if you're moving. A, if you've never done it before, [00:13:00] but also I guess if you're moving off a A fully PSTN based or switch like, you know, what I'd call an old school phone system, you know, where you're not using voice over IP and you've never tried to put all your voice onto the network before. 
 
 

Alex Baker: Yeah, definitely. Yeah. I guess these days, what with teams and voice over IP being more prevalent, maybe that's unlikely, but yes, it's definitely a consideration. Can our current infrastructure cope with what we're trying to put in here? The next point I had to mention is around timescales. So how long do you have? 
 
 

What's likely to take a long time? So, for example, number porting, it can add some quite long lead times and it can also, those lead times can vary quite hugely between countries. You don't want to have that being the limiting factor, so we know that you can effectively migrate to Kinect pretty quickly. 
 
 

Do you want to plan your migration for sort of next Tuesday, but then be limited by the fact that you're waiting 90 days [00:14:00] for your, your number porting to happen. Yeah. And  
 
 

Tom Morgan: that's one of those things that is pretty much out of your control, isn't it? It's going to be down to the carrier. And guess what? The carrier is losing a customer essentially. 
 
 

So like they're not super incentivized to make it quick either.  
 
 

Alex Baker: Yeah, you've got wherever you have that, that the sort of legacy provider as a consideration, yeah, make sure that you have as, as much as possible buy in from them. And if maybe they support your your, your, your legacy platform, can you get them to be around for the migration so that they can redirects and configuration changes? 
 
 

Okay,  
 
 

Tom Morgan: cool. Yeah, that makes sense. That really makes sense. What I'm kind of thinking, I'm thinking more of these kind of migration scenarios than like the brand new ones. And understanding like what's important and I think a tendency of customers that I talk to often is to say, well we have like a working contact centre over here and we've used it for the last 10 years and we've got all our processes down and all our staff are [00:15:00] trained. 
 
 

We just want to, like, have exactly, you know, we want it to work exactly the way it does here over on Connect. That's what we want, like, you know, process stays the same. And how important is doing that or how much should you do that versus sort of an alternative approach, I guess, which is like you're moving to the new, like, this is a good chance to revisit everything, you know, and start again. 
 
 

Alex Baker: Yeah, great question. A few. Questions and considerations around that, I guess. It's possibly going to depend on some of the things we mentioned earlier. For example, have you got a tight timeline or deadline to replatform a lot of staff? If so, that lift and shift type approach might be appropriate as a first phase. 
 
 

If you need to meet those deadlines, it might be easier just to sort of get everything across and then you have the new platform to expand on and, and, and iterate on with, with future releases. Also, what resources have you got available? [00:16:00] Would it be possible to have say a transformation or migration team to, to get that initial migration out of the way, but maybe closely followed up by an optimization team? 
 
 

That could be quite a nice approach. We've had some success with sort of writing migration tools and bits of code to extract data from legacy platforms and automate some of the configuration. That's quite nice where you've got a legacy platform that has APIs where you can use those APIs to pull the data from the platform and maybe even get it into some of the right format that you need to import the data interconnect. 
 
 

Having said that. It's always worth reviewing what you're bringing over. So you mentioned the sort of 10 year old platform, it's possible there's. There's some sort of fairly, fairly old configuration in there. Do you actually need it anymore? Do you want to bring it across? There's that, that old phrase, sort of, garbage in, garbage out, right? 
 
 

So make sure you're, you're actually bringing over [00:17:00] everything you need, rather than just stuff that's, that's, that's there for the sake of  
 
 

Tom Morgan: it. And maybe treat it as an opportunity to have a bit of a sprinkling. You know, do you need those old flows from the promotion that you ran 20 years ago, or whatever it is, you know. 
 
 

It's like, it's like anything, isn't it? Like there, you know, there are quick as there are some shortcuts, but there's probably no such thing as a free lunch.  
 
 

Alex Baker: Yeah. And you know, it's, it's giving you when you move across to connect, even if you do do that sort of lift and shift and, and start with the basics, you've got that amazing future proof platform to expand on, so. 
 
 

Even if you don't do that straight away as part of the transformation, that would be great. But sometimes it's not possible. You can go back and revisit quickly and start to run. You can  
 
 

Tom Morgan: add  
 
 

in the features, right? You don't have to do it  
 
 

Alex Baker: all on day one. And we mentioned, we've mentioned it a couple of times, but yeah, run those little proofs of concepts, take a. 
 
 

Take a smaller business unit and try out your, your voice biometrics or your, your Lex speech bot type [00:18:00] capabilities, do it in a, in a, in a small controlled POC, figure out if it, if the business case stacks up and then you can roll it out to the wider business. Yeah, that makes  
 
 

Tom Morgan: sense. As we're talking, it's kind of becoming clear to me that there are some steps here. 
 
 

There's like the pre work, there's the planning and how important it is just to. Really have a plan and just not sort of walk sideways into it or backwards into it. You know really sort of think about it before you start to make sure that you get that pre work done. You've highlighted the things that could take a long time to understand what to have a think about what your actual approach is going to be which makes sense. 
 
 

Like it's a, it's a big, it's a big project for any company. You know, it's such an important part of this, you know, the process of dealing with customers, the customer experience cycle. It's so it's such an important part of that, that you want to get it right. Right. And it is important but it's also, you know, we, we see it rushed sometimes, right? 
 
 

So, yeah, it's worth  
 
 

Alex Baker: saying. Yeah, agreed. And I, I think with, [00:19:00] it's difficult, isn't it? You, you can, because we can make it easy to do that sort of lift and shift. Yeah, potentially that's the, the easy route. Also give it a bit of thought, like we've said, think about what, what your, what your desired outcomes are and, and try not to sort of take across 10 years worth of, of of legacy stuff. 
 
 

Tom Morgan: Yeah, absolutely. Yeah. So we've got our plan. We've worked out what we're keeping, what we're getting rid of. We've done our pre work. We're kind of ready to go and build our shiny new instance and we know what's going to go into it. What should we do? Should we build it first on the side, because you can do, right? 
 
 

Because it's, it's all consumption. Basically, you build this whole thing out with nobody using it and you basically won't pay for it until you start using it. Should you do that and just get it ready to go? Is that a good approach? Do you think?  
 
 

Alex Baker: Yeah, I think it's always worth having some sort of sandbox environment. 
 
 

And this might depend on what we discussed earlier around the organization's wider approach to cloud migration. But yes, would as a minimum suggest sort of having a, a dev environment and a [00:20:00] production environment. And then if you're moving into sort of infrastructure as code, possibly dev, UAT, production environments, maybe even more depending on, depending on the, the, the widely accepted setup amongst the rest of the organization. 
 
 

Also things like your integration. So if you're integrating with a Zendesk, for example. What do you have in terms of the pre production environments for those those other systems? Do you have, you know, dev and UAT for, for Zendesk? If so, perhaps it makes sense to have something matching for the Kinect environment as well. 
 
 

Tom Morgan: Yeah, that's true. And that's, that's a gotcha point as well. Actually, if you don't have one of those things, because I've seen this before, where you're doing your integrations, but you've only got You've only got one version of Zendesk. Let's say you haven't got those kind of test environments or anything like that. 
 
 

So you do your integration to the live, you've got to really make sure that the people using your test instances of Connect know that they're using the live version and not also a test. It's the cut over. It's the integration between environments. You kind of got to be [00:21:00] careful. It's, it's interesting. 
 
 

It's funny as we're talking, like I understand that those words that you're using around different environments, like a dev environment, a UAT environment, because I'm a developer, we're both developers, right? We've come from that heritage. It's, yeah. It's still developed like if you're configuring, I don't know, maybe this doesn't need to be said, but I think it's worth saying, like, if you're configuring Amazon connect, you don't have to be a developer, but. 
 
 

You are kind of changing how the platform works and so I don't want you don't like, I think people should have a development environment, even if they don't have any developers and they don't plan to ever do anything that they would consider development, it's really about that's a space for you to try stuff out, try out a new feature, lean into some new announcement that you saw, try out and see if you like it. 
 
 

If you don't, never mind. If you do, then think about, okay, how would this work for our company? How would we configure it? How would we get it right? And then making those changes and pushing them into the next environment up, which might be UAT, user acceptance testing, and then from there up into production, it's more about having that sort of sandbox. 
 
 

If you like a space to [00:22:00] play traditionally, that's where you put developers because when they break stuff, it doesn't matter and they can get it right there first before you push up the environments. But I just want to kind of highlight. We call it the dev environment because that's the history, right? 
 
 

But actually, Today's connect people like, yes, there are developers and you can develop on connect, but there's probably a whole bunch of people who are just configure connect rather than  
 
 

Alex Baker: develop on it. Yeah, and maybe from a more of a legacy contact center perspective, sometimes it wouldn't necessarily follow that. 
 
 

You'd have two different environments because it was difficult and costly to set that up. So you might have a sort of ring fence part of. The main environment where you'd set up sort of test call flows and things like that, but not necessarily a full on split between Dev and production. Whereas now it's so easy and cost effective to have multiple environments. 
 
 

And like you mentioned, keep any unintended consequences away from production. Why wouldn't you do that? Yep,  
 
 

Tom Morgan: absolutely. So when you've got. Your development environment, your [00:23:00] UAT environment up and running, maybe even your brand new contact center is ready to go. How do you get people using it? How do you go from the old to the new? 
 
 

What's, you know, you've got some options, right? You could, you could run them side by side for a bit. You could turn it off and turn the old one off on Friday, turn the new one on a Monday. There are some different approaches people can take, right?  
 
 

Alex Baker: Definitely. Yeah. And. Potentially it might come down to a few things, maybe the, the size of the business, are we talking a contact center of sort of 50 agents or all in, in one business unit or team, or is it 2000 based in multiple locations across the globe? 
 
 

What's your appetite for risk as an organization? Could you do, could you could you handle doing a sort of big bang migration approach? And if so, would you actually want to, or need to are there any? Benefits or any considerations around doing that is there a need to do that? I think it's, it's quite often useful to start small, run a pilot on a team or a business area, [00:24:00] test out your migration procedures, see everything in action, get hands on with the tech, and then you can refine your approach for the rest of the business from that. 
 
 

Yeah, that makes sense. Yeah. I, I think I mentioned this already, but you, You want to ideally have some sort of hands on control of the legacy solution for this bit. So being able to quickly redirect traffic between all the new platforms, if you need to, that's really valuable. As I mentioned, that does become a bit more difficult where a customer relies on a service provider to make any changes. 
 
 

On that legacy platform, you would then need the buy in of that third party. But yeah, it's very useful if something unexpected occurs during your migration, just to be able to sort of turn things around and really quickly send the traffic back to the legacy. Start  
 
 

Tom Morgan: again. Yeah. Yeah. That makes sense. Yep. 
 
 

Alex Baker: Yeah. Yep. Another consideration is around costs. So potentially. [00:25:00] You're going to have the cost of running multiple contact center solutions for the duration of the project. And there's, there's going to be some period of dual running where you're going to be incurring costs on both. So take that into account. 
 
 

First of all, when writing the business case, take into account those dual running costs and try and minimize that cost impact where you can. So have a plan for things like downsizing your legacy licensing. So you're not paying for a thousand contact center licenses for the next year that you're not actually using. 
 
 

And for decommissioning old kit, whether it's in data centers or on site just so that it doesn't continue to, to cost you money.  
 
 

Tom Morgan: Yep. Great point. And on that actually, like once you do have both things up and running and you're off to the races with the new system and then you turn off the old system are you, are you done? 
 
 

Is that project finished? Like, you know, how Like, what, how should you look after an Amazon Connect deployed instance, I guess and that might be, because it might be different to how you previously looked [00:26:00] after your previous contact center installation.  
 
 

Alex Baker: Yeah. And one good thing is that Amazon Connect is generally a bit more low maintenance than, than a lot of legacy platforms. 
 
 

There's no service to patch. You get your updates. transparently rather than needing an outage window. That's a big benefit in itself. I never thought about  
 
 

Tom Morgan: that, but yeah, of course, yeah. Features just show up and somehow they're added to your instance.  
 
 

Alex Baker: I'm sure lots of people like me who've worked in telecoms for a while, probably remember long weekends and late nights in comms rooms and stuff, performing system updates. 
 
 

And you luckily don't have that with, with Amazon. Somebody does, but it's not us. Yeah, that's right. Also in terms of the. How to look after it. We, we at cloud interact always kind of advocate strongly for taking our customers on the Amazon connect journey with us. Sorry if that sounds a bit cheesy, but  
 
 

Tom Morgan: what does that mean  
 
 

Alex Baker: by that? 
 
 

I guess. I mean, we, we, we want to work collaboratively with the existing teams. You [00:27:00] know, our customers, we make sure they're a part of the transformation, make sure as they progress through the transformation, that they're getting upskilled so that they can be self sufficient or as self sufficient as possible come the end of the transformation. 
 
 

So at some point, you know, we're, we're going to leave the project. We want to leave the, the team that's there with the skills to be able to do what we've been talking about, right? So. optimize where possible. They've got this great platform that they can continue to iterate upon. We want them to have the knowledge and the confidence to be able to do that. 
 
 

That makes sense.  
 
 

Tom Morgan: Yes. Yeah. And I know, I know AWS have good resources as well for kind of keeping on top of that stuff. So like once. Yeah, once we leave and sort of left you, you know, with everything we know at that point in time, you staying on top of the technology is important and is part of what it means to look after a contact center. 
 
 

I think, you know, keep you up to date with new features and announcements and [00:28:00] things like that. But, you know, AWS do a good  
 
 

Alex Baker: job of that. Yeah, for sure. And. Throughout the whole transformation journey AWS are always very helpful at things like running Amazon Connect boot camps for a customer's technical staff, and there's, there's loads of great resources on, on the AWS website and elsewhere around running an Amazon Connect contact center and troubleshooting and a whole load of different things that are going to be really useful for that ongoing life of the product. 
 
 

Yep,  
 
 

Tom Morgan: absolutely. What else should you do? We come sort of probably come to the end of our time. I think it's going to be a long one. You're right. You were good predictions. So what should we do? Or what should people do to kind of just yet that keep you on top of stuff? You keep up with the training that makes sense. 
 
 

Keep you on top of changes and new features. What else should you be doing, you know, the sort of care and good maintenance, I suppose, of a contact center?  
 
 

Alex Baker: We, or I specifically mentioned the Amazon Connect release notes quite a lot. [00:29:00] Sorry if it seems like I bang on about those, but it's a really useful source of, of updates, what's happening. 
 
 

And  
 
 

Tom Morgan: if you don't want to read them, you can just listen to Alex  
 
 

Alex Baker: every week. Yeah, exactly. Yeah. And also we do Cloud Interacts. Put a review of those out on LinkedIn every month as well. So keep an eye out for that. But they're really useful because we mentioned that the, the update processes is quite transparent. 
 
 

Actually, you can just be carrying out your, your normal business and working on connect and you might not. Notice that it's  
 
 

Tom Morgan: almost by design, isn't it? That new features don't impact existing installations because that you don't want that to happen, obviously, but yeah, the flip side is you can be blissfully unaware of stuff if you don't  
 
 

Alex Baker: lean into it. 
 
 

And some of them are smaller, you know, not massive new new features, but they're they help with the UI or help with the usability of the product. So yeah, definitely worth keeping an eye on that. I would also related to that bookmark the connect admin guide. Check out the document history section in there [00:30:00] just to track any updates to the guide. 
 
 

It's quite a comprehensive guide. Probably quite difficult to, without looking at that history to, to to see what's been, what's been changed. A couple of other things to recommend. There's an AWS blogs page within that, there's a customer engagement section. There are regular blogs posted about connect both from AWS and from partners with some great things to, to just read about. 
 
 

And also some some cool things to, to try and build. That's cool. Join some groups on LinkedIn. There are a handful of great Amazon connect groups on there. And as I mentioned, we, we also post things like the, the release notes round up every month. And then the last one for me to mention, keep an eye out for AWS and Amazon connect events. 
 
 

For example, in April, there's an AWS summit in London. Or later on in the year, the biggest date in the AWS calendar is reinvent, which is a sort of early December time usually usually, and that's in Las Vegas [00:31:00] and quite often, some of the biggest announcements of new features and services coincide with reinvent. 
 
 

So that's a big  
 
 

Tom Morgan: one to look out for to look out for it. And then like, if you can't make it to Las Vegas or you don't want to make it to Las Vegas. I understand. I quite like it, but lots of people are anti Vegas for some reason. But all that stuff goes online as well, right? So, like, you can all, you can watch the talks and get the information. 
 
 

You don't have to be there in person. Yeah, watch  
 
 

Alex Baker: the keynotes and, and quite quickly afterwards get a, a sort of roundup of all the, the the key announcements and feature drops and everything. Yeah, yeah,  
 
 

Tom Morgan: no, it's, there's a lot to take in really. It's, if, if you're moving, you know, from a very legacy contact center into Amazon Connect. 
 
 

It's a different way of working to like look after and maintain a contact center is it a different set of skills and I think it's worth remembering that and so yeah, no, this has been really, really useful. Yeah, we've gone on a bit, but actually it's it's super interesting and it's but it's Really important stuff as well. 
 
 

So, yeah,  
 
 

Alex Baker: like we said, there's, it's a [00:32:00] big topic, isn't it? And I think hopefully we'll cover a bit more in another session around the sort of project methodologies that people  
 
 

Tom Morgan: consider. Yeah, it'd be really good to get some of our people in actually and talk to them about that stuff. Cause I know that they're talking to customers every day. 
 
 

So they'll have some really interesting insights, I think. Yeah, agreed. Fantastic. All right, let's bring this episode to an end. Thank you very much, Alex. Thanks Tom. Great to talk to you again. Thank you all for listening. A reminder that if you have questions, you have feedback, you can always get in touch. 
 
 

You can get in touch on LinkedIn or you can email us at podcast at cloudinteract. io. Today, we discussed deployment of your Amazon connect instance and things to think about next week on ACP. We're going to be talking to the CEO of sequence shift, Dimitri Muntin about PCI compliance with Amazon connect. 
 
 

So be sure to subscribe in your favorite podcast player. That way you won't miss it whilst you're there. We'd love it if you would rate and review us. And as a new podcast, if you have colleagues that you think would benefit from this content, please let them know. To find out more about how Cloud Interact can [00:33:00] help you on your contact center journey, visit cloudinteract. 
 
 

io. We're wrapping this call up now and we'll connect with you next  
 
 

Alex Baker: time.