Welcome to ACP

Speaker 3 0:02

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, and I'm joined as usual by my co-host, AWS solution architect and contact center consultant, Alex Baker. We are also joined this week by Mark Pritchard, senior platform and automation consultant at Jabra. Find out more about Cloud Interact by visiting us at cloudinteract.io.

Tom Morgan 0:34

It's time For another ACP. You're with us again on a fairly sunny, fairly warm day in the UK. I think it's pretty warm everywhere in the world at the moment. Alex is with me. Hello, Alex. How's it going?

Alex Baker 0:46

Hi, Tom. Yeah, good, thank you. Yes hot, enjoying the weather. It's school holiday, so got kids running around in the garden as well, which always adds to the chaos

Tom Morgan 0:55

Absolutely. I promised myself this year I would not complain about the heat because I'm-- I much prefer it hot than cold. And I was just talking to... We should introduce Mark. Mark's also here as well. Hello, Mark. And we were just talking, weren't we, about about the weather, complaining as we do.

Mark Pritchard 1:08

Yep.

Tom Morgan 1:09

You were telling us not to be so silly because you were somewhere much hotter a couple weeks ago, so you know

Mark Pritchard 1:14

Yeah, it was much hotter and yeah, much more humid than it is here in the UK. But yeah, it feels cooler being back here, so yeah

Tom Morgan 1:21

Absolutely. It's great to have you with us.

Meet Mark Pritchard

Tom Morgan 1:23

Let's kick off with a little bit of an introduction about yourself then. If you could just fill us in about your background a little bit a- and and we'll go from there

Mark Pritchard 1:31

Yeah. Thanks for the opportunity of coming on today. Yeah, I-I-I'm Mark Pritchard. I've worked now for GN or Jabra, as you guys may know it for now just over fifteen years, so quite a, a long-standing employee with them. I was previously working inside GN, which is the main part of the business that looks after GN Hearing and also Jabra, which is the hearing side of the business. I was previously a, a senior IT support engineer basically supporting three of the main locations that we had in the UK on basically anything and everything to do with IT including mobile telecoms, fixed telecoms, anything from there. I kinda built my IT career, mainly started many years ago back in the 2000s when I was working in motorsport. So I used to work for a Formula 1 team many years ago and kinda built up all of my IT knowledge as well as kinda telecoms knowledge all those years ago. I started out with Ericsson MD110 systems with the old bell wires and chrome tools and test telephones. Matching up your equipment number to your floor box which was pretty good fun back in those days. Swapping out cards in the old Eri-Ericsson systems when they failed. And then kinda moved on to Avaya IP Office systems which we used to have inside GN what, quite a long time ago. And then into the last system that I kinda looked after, which was Competellaa, which was a, a Danish-based voice platform, but on-prem. The whole system was pretty much designed around Voice XML files, so you literally had to edit a Voice XML file in order to modify an IVR. And if anyone's ever worked with Voice XML, you put a full stop or a space or a carriage return in the wrong place, it doesn't just stop that part working, it just destroys the entire IVR in one button click, which yeah

Tom Morgan 3:16

Keeps you on your toes. Yeah

Mark Pritchard 3:18

Yeah, it definitely keeps you on your toes, definitely pleased to see the back of that one,

Tom Morgan 3:21

I knew of Jabra before I knew about GN, but you think of Jabra, I think headsets, I think, audio devices, I think high quality sound for meetings and stuff like that. And then it's GN and that's, hearing aids, I believe. Is that right?

Mark Pritchard 3:34

Yep. It's the hearing

Tom Morgan 3:35

so it's all kind of high quality audio. So you imagine that actually internal to the company, and this is sometimes the challenge with IT companies, right? Everybody assumes that of course, they've got the absolute best setup. Everything is perfect because it's a whole IT company, and they care so much about audio. But how is that-- is that true? Is it, how's that on the ground? Is it or is it just like any other company?

Mark Pritchard 3:55

Yeah, I think it's like any other company. We have some amazing setups of some things internally, and we have some atrocious setups of some things internally, but I think headsets-wise, obviously being Jabra we are very lucky that we can use any headset we want internally, which can prove its own challenges with Amazon Connect. We've got certain headsets, especially wireless headsets, that some of our agents might be using when they're troubleshooting some of our customers' problems. They're swapping between headsets a lot. That can prove quite challenging with Amazon sometimes. But yeah, we do try and keep up as much with technology as we possibly can when it comes to using our own headsets, in terms of what we're using inside our own call center. So yeah we do have some bad setups and also some very good setups.

From On Prem to Connect

Alex Baker 4:39

What was it that led you into the path of Amazon Connect and what your experience is there to start off with?

Mark Pritchard 4:46

Yeah. So we got led into Amazon Connect really off the back of a need for getting rid of or updating away from Competella. So the on-prem platform that we had, as in Competella, was getting towards the end of its life really. We had multiple on-prem servers dotted everywhere. We had audio codes, boxes everywhere. And in terms of saying, about bad setups and good setups it wasn't the greatest of setups, if I'm really honest. Myself and Morton Denali used to look after that along with a whole host of other people. And the business decision was taken that we were going to move away from it and go to Amazon Connect. So that decision was taken right at the top of the tree that we were moving to Amazon. We looked at other systems but really kind of Amazon was the one that was chosen by the, the people at the top. We migrated away from Competella, which was a, a full on-prem platform as I say, using the voice XML side. And then we brought in Amazon Connect as a major project. We worked with a vendor that helped us install that system or helped configure but nobody had any knowledge of AWS or Amazon internally in IT at that time, or in the telecom side. As in me and Morton had no knowledge of that at all. So we really were in their hands to begin with. So yeah.

Tom Morgan 6:03

What sort of time was this? Just generally, like in terms of, was it pre or post-lockdown is what I was thinking

Mark Pritchard 6:08

It was just after COVID. So yeah, we started that project in 2021.

Tom Morgan 6:12

Yeah. So you'd already had some of that pain of everybody at home having to deal with an on-prem system like VPN or whatever it is that doesn't work very well with audio and all the rest of it. Yeah.

Mark Pritchard 6:22

Exactly. And,

Alex Baker 6:23

did that did that accelerate the decision so

Mark Pritchard 6:26

I think it highlighted the fact that we were able to cope with the Competellaa platform based the fact that people working from home were still able to access the voice platform via the VPN. We still survived in that way with people working from home, but it highlighted how much we had a need for things like Teams. Teams, what we wouldn't have done without Teams and having file sharing at that time through Teams and everything. I don't know what we'd have done. Obviously, I know this is an AWS kind of discussion,

Tom Morgan 6:55

No we've all been through that. I think we've all been through that journey of suddenly those tools that were sometimes helpful suddenly become critical, don't they? Yeah.

Mark Pritchard 7:03

they did. And I think after, after the COVID after we got out of the other side of that, it highlighted that we really did need to have something that was a lot more cloud-based and probably easier to look after because any changes we had to make with the Voice XML side and the kind of-- it was very clunky the way it had to work. It wasn't very graphical. We had a lot of challenges with it. So yeah, I think it was evident we needed to find a way of moving away from it

Alex Baker 7:27

And presumed because it GN, Jabra, a big global organization, did, did that sort of factor into it at all? Or w- or, what were your challenges, if you had any, around it being such a big diverse global organization?

Mark Pritchard 7:40

Yeah, we had a lot of challenges when it came to migrating to Amazon Connect. We've got four instances as it stands at the moment, so we had to split everything up across multiple areas. Challenges we had, I suppose really was lack of knowledge to begin with. We had to work very closely with a partner. But yeah we did have quite a lot of challenges.

Tom Morgan 8:03

But yeah. No, that's interesting to hear, though. Really interesting to hear 'cause we often say that Connect can be such a toolbox of things. It can do so many different things, but you do need to know that it can do those things before you even start with how it can do those things, so there's almost a reset, if you like of expectation or understand or thinking about what you want from first principles almost. And

Mark Pritchard 8:25

yeah.

Global Instances Strategy

Mark Pritchard 8:26

The overview of what we've currently got, we've currently now got four instances that we're running. So we're running EU Central, US East, Singapore, which is now looking after India because that's the closest we can get for India and also Japan. We've compared to what we had with the on-prem platform this is now, just as vast. But yeah, we have multiple instances now that we're using.

Tom Morgan 8:48

And do they-- Are they-- I guess they all differ slightly in configuration and setup for the various local needs, or do you try to keep them aligned?

Mark Pritchard 8:55

We try and keep them as standard as we possibly can. So for example, in the US, we have about 15 flows everything from our enterprise customers, which are dealt with in the US. We have our store customers. We have various lines coming in for Blue Parrot, which is another area of the business. We've got our Jabra Care customers, which are our customers that pay for that extra level of service. And then in Europe Europe is where all of our enterprise customers come in on the language side. So we have 13 flows inside Europe supporting anything from French, Italian, German, Polish, Spanish, and so on. So yeah, we do try and keep a standard. All of our IVRs in Europe are all identical. So if we have customers that come through in Germany, for example, or in France, and they've come through to the wrong location for whatever reason, our agents know that if they're looking for technical support, they can give them the telephone number for Italy, for example. They can transfer them, of course, but they would transfer them, say to them, "If you want to call back on this number, it will be option two." And they know that is the same across all IVRs.

Tom Morgan 10:04

That's nice

Mark Pritchard 10:05

we also try to keep the same standards as well with our scripting. So anything where a customer goes into queue, or they go to an IVR, or we give them extra messaging, call back, we do try and keep the scripting the same, which makes it a lot easier to manage when it comes to making scripting changes or anyone wanting to know what those scripts are globally, they are the same. So yeah, we do try and keep some standardization as much as we possibly can.

Alex Baker 10:31

Yeah, it always helps not having to go back and think about how you've configured it for Singapore compared to Europe, for

Mark Pritchard 10:37

Yeah.

Simplifying Flow Design

Mark Pritchard 10:38

And I think that's probably the challenges we had when we worked with the implementation partner right at the start, is that it was designed around being very complex, extremely complex, with multiple flows feeding into another flow, and then an output from there into another flow, and it was constantly connecting to different flows. We've adopted a lot more now where we will have-- For enterprise support, for example, I have one single flow that looks after everything for enterprise support. Then I have one single queue flow that deals with all music on hold, callback, and so on. But that's across the board, across the whole of the US. So rather than having a queue flow per division, I now have one queue flow which is used for everybody. So it just makes life a bit simpler. Especially the fact that it's only really Morton and I looking after this in all regions globally. So EMEA, APAC, North America it's only two of us. So we have to have something which when we need to do something quickly, we haven't got to think, "Oh, okay, that's going into there, and that's going to there, and that's going to there." It's very easy to try and troubleshoot, or at least it is for us now. Someone else coming in may look at those flows and go, "Wow, they're enormous. How do you ever look after that?" But we know what we're doing with them now, and it's a lot easier with having one flow. But you do need a very large format screen, as we found out, which I think we've both now got thirty-seven-inch ultra-wide curved screens on our desks because when you've got these flows, if you've got a twenty-seven-inch normal screen on your desk, you can't see them. Hence the reason I don't work from the office very often on my laptop lid anymore because

Tom Morgan 12:17

You can't

Mark Pritchard 12:18

without a wide screen.

Alex Baker 12:19

Where's the struggle with... Oh, there you go. I feel like I need to need to upgrade my monitor now you've

Tom Morgan 12:24

good justification. Yeah.

Mark Pritchard 12:25

yeah, exactly. Is it--

Tom Morgan 12:26

Yeah, that is a really interesting point though that so w- we see it with different companies. It's really important when you're designing these things, obviously take into account the service owners and those running the contact center and what they want. But actually or it's also important to talk to the people who are gonna be looking after it, and it's almost designing for those people as well, like you were saying. It changes how you can still deliver the same outcome to people, but you can do it in several different ways. And being clear about what you want because you're gonna have to be looking after it, I think, yeah that's really important.

Mark Pritchard 12:56

We made one very small change to a lot of our flows when we redesigned stuff a few years ago, where rather than just attaching telephone numbers to a flow and then using the phone number section inside Amazon Connect to see where those numbers are connected to and then keeping records, we actually make sure that we put an attribute block right at the start of every single flow that has the phone numbers that relate to that flow in it. So it's extremely easy then that when you access the flow for enterprise or store or whatever it is, and you want to see the phone number that's on the website, and you want to trace that through, you haven't got to go and look in phone numbers, see which flow it's connected to and everything from there. We just go to the store flow, look at the attribute block, see where the telephone number is, and then just literally trace it through and find out which queue it's connecting to. Just makes life a bit simpler and a bit easier, and we've adopted that across the whole of

Governance and Number Porting

Mark Pritchard 13:46

everything now.

Alex Baker 13:46

Do you find that having moved to, Connect from from Computella it's easier to give the, the business users a bit more freedom to do stuff as well? Or is it mainly yourself that, that still does that config?

Mark Pritchard 13:58

Yeah. Uh, IT are the, are the owners, obviously, of the voice platform. Um, IT are quite strict, obviously, with who has access to the back end of the platform and who has access to be able to modify and update within that platform. So- think it's given us, as in people like myself and Morton, a lot more flexibility now and a lot more visibility to be able to manage what's going on in the system. In the old Competella system, we really struggled with telephone numbers. We had so many providers for phone numbers globally. It was ridiculous. One of the parts of the project when we swapped over from or migrated to Connect was that we wanted to use Amazon to host all of our phone numbers. So from twenty twenty-one onwards we've migrated pretty much all of our phone numbers that we have. I would say we've got ninety-five percent of our phone numbers now are in Amazon Connect, which just makes our life so much easier. We haven't got to think, "Oh, that phone number's gone down," or, "The quality's bad. Who's the provider?" We just literally know it's in Amazon. We've got certain phone numbers which we can't host out of Amazon, like India, for example, which is a real challenge. But yeah, I think-- with the birth of kind of the AI and the portals and everything, that has definitely given our managers and our team leaders more access and more visibility. But I think we did, in answer to your question, Max, we probably struggled at the start, I would have thought, more than we do now with visibility inside Amazon Connect compared to Competella and other platforms we'd used. That was one thing which I think our agents and our managers and team leaders struggled with a little bit, where they were just presented with a CCP panel on the screen, and it was like how can I tell who's in the queue?" You can't." "Well, Build you a dashboard for it." "Okay can I take a call out of the queue if it's stuck?" "No, you need to let it flow through naturally. We don't do it like that anymore." And it's-- there was cer-certain things which the visibility did drop right off. It's definitely built back up now. We have more visibility in here now than we've ever had. So yeah.

Alex Baker 15:58

I, yeah, I guess it's nice that you have the power more so than a lot of other platforms to just build your own solutions to things. And it sounds like as you said we'll get onto this a bit more, but you guys have been so hands-on in terms of taking the out-of-the-box system and then developing on top of it perhaps with a sprinkling of AI. It sounds like you've used AI tools and you've seen a business problem, and you've then been able to develop something around it to use in Connect, and you've done that on quite a few occasions by the sound of it.

AI Built Callback Portal

Mark Pritchard 16:27

Yeah. The journey has been-- I suppose it's, it started really with our callback journey. So originally we had a third-party platform that we integrated into Amazon Connect for callback. So when the customers went into queue and they pressed one to request a callback that came out of Amazon and went into a third party where they processed it and then pushed it back into us. With the increase in knowledge that Morton and I developed over the years, we looked at it and went, the amount of money we're spending on this, I don't think we need to do this anymore. I think we could pretty much not copy their solution at all, and it's not a copy process. It was more a taking all of the things we'd learnt from that callback journey and build our own inside Amazon as a native kind of setup. And we did. And then we built a standard solution. We then built on it even more, customized it, and then made it pretty much bespoke to what we have now. But the thing we missed out on was the visibility that our managers and some of our agents and team leaders had was that we had a portal for the callback Which the managers and the team leaders were able to see whether the callback was successful, whether or not it was a retry. So in other words, the, the customer hadn't answered the first time and they were managed to get through the second time or so on. How long it took the agent to answer the call. We did have some instances in the call center where agents were avoiding callbacks, and the portal would show us that really easily, so the managers wanted to see. It gave us a lot of flexibility as well as a little bit of reporting in there as well, where we could see how many callbacks had come in daily, weekly, and so on. We could do that in Amazon, but it was just a nice portal. It looked really good. As well as ending callbacks and all the other stuff. And we did all the callback flows and redesigned callback, pushed it out into production inside Jabra and part of GN Hearing, but obviously we lacked the portal. Someone introduced Morton and I then to Cursor all those months ago. And Morton, and I'll give him a big say here. Morton started out by looking at what he could do with just creating like a standard like website. He was thinking how can I use this?" And then he thought that works." So he introduced me to it, and then we thought I wonder if we connect it to Amazon, can we do that?" So we found the CLI that we could use through Visual Studio, which was just a PowerShell script. So we tried it on the development instance and then, literally the rest is history. We then thought, "Wow, look what we could do with this." So we started designing a portal, which was pretty much taking what we had with the third party and taking all those pieces that we really liked and then making our own. And I think it probably took us about two, three weeks to get our heads around it, and then we started using Visual Studio with GitHub Copilot, and then that's where it exploded. We took on then the GitHub repository where we were storing all of our projects. So it really started with the callback journey, and then it moved on then to looking at where we wanted to have visibility, but we couldn't because we weren't developers. We didn't have the budget. There were certain things we wanted to do where it's like, wow, that's going to cost us a fortune if we use a developer for this. And our own in-house developers inside the business were busy on other projects. So we, we couldn't get any seat time as such with them. So we thought maybe we'll try this." So we tried it, and then we built the skills-based routing portal so we could give the managers access rather than having to use these vast spreadsheets that we had. And that's really where it went, Alex. It was just... Yeah, it ballooned from there really into what it is

Skills Routing Self Service

Mark Pritchard 20:00

now.

Alex Baker 20:00

I really like the, the-- You mentioned the skills-based routing portal, 'cause that's a, a classic thing of and I guess my earlier question around giving the business a bit of power to do things. So the, the day-to-day routing changes, right? That's always something that people are asking for, for them to be able to do and have a bit more flexibility around. So sounds like that was a really useful one to put in.

Mark Pritchard 20:21

Yeah, I mean that, that led to a few other kind of questions from some people over the past weeks. Why do you need to be able to change skills-based routing? Surely you set it in stone and then you don't change it. Yes you shouldn't be changing it, but we had a need where when certain agents went on holiday, it meant that the routing steps we had, it would've taken longer for a customer to get to an agent with that agent being on holiday. So it was just quicker to go and update their proficiency. So we had a need for it, but it was unique to us. Other companies might not wanna do it like that, but by creating that portal and sharing it like we have done now, it now means somebody can take it and then tailor it to how they want it to work. And I think that's-- So yeah, the skills-based routing was one of them amongst a whole host of other stuff that we've created now.

Tom Morgan 21:09

I love those, some of those use cases 'cause they're exactly where AI development can be really helpful, right? You were never gonna get the budget to build these things, it was never that important or that critical. We would've just gone on without it, but it actually is providing additional value, and it's super useful, and actually comes back to some of that IT lockdown stuff as well. It's like these things were hard to do because, IT generally like things not to change because change is dangerous. But it's doing it, in a ni- in a measured way, in, in a controlled way that you're it's great. Like it's you're making it easy for both ends of the, both sides of the puzzle almost.

Migration Portal Project

Mark Pritchard 21:43

Yeah. We've obviously got some fairly big projects going on at the moment. So we have a huge migration going on at the moment within the business. The hearing side of the business has basically been bought by a company called Amplifon. So we have about five thousand employees, I think, which are going to be migrating across to Amplifon. Which obviously leaves about two and a half thousand people or so left, which will then still be GN, Jabra, and various parts. So we've had a lot of challenges recently where AI and, Bob, because that's the easiest way to talk about it, yeah, has come in handy. Where we've had to migrate all of our Amazon Connect instances away from the current instances to brand-new instances. So we had some huge challenges where we have to literally take all of our flows that are Jabra flows and other flows away from GN Hearings flows and put them into new instances. Now, you guys have all worked with Amazon before amongst a lot of other people that will probably be listening to this podcast. That's quite a big feat, especially when you think about we've been working with it since twenty twenty-one. There's a lot of stuff inside those instances. A lot of stuff we developed, built huge flows, some of them that can't actually be exported because they're actually too big, which isn't a great design in some ways, but we've had to work with it as best we can, apart from splitting them up. We had to work out how we were gonna do it, and we actually have to get this done by the end of the year so we actually developed a migration portal. So using GitHub Copilot, we've basically developed a migration portal that enables us to connect the current instance and connect the new instance on completely different account numbers. And then we can select what we want to migrate from one instance, as in existing, to the new. So rather than having to export flows, we literally get AI to do it for us through this portal. It's taken us a while to do it, and it's still in development, but it's saved us so much time.

Alex Baker 23:42

Nice to be able to be selective as well about what you bring across there rather than just wholesale. It's probably quite a good time to say, "Oh, this is from twenty twenty-one. Maybe we don't need it, so we're not gonna bring this group of queues over," and just select which ones you, you do take.

Mark Pritchard 23:56

Yeah, and I think what was really interesting when we built it, we obviously did a whole plan and a design of what we wanted to build and obviously fed Bob with this information.

Bob the AI Teammate

Alex Baker 24:06

Sorry Mark to interrupt, but so you mentioned Bob. I think it's quite good. So y-yourself and Morton have named your kind of AI co-colleague as Bob, right?

Mark Pritchard 24:15

Yeah, there's a few reasons.

Tom Morgan 24:16

Is he on the payroll? Is that how it works?

Mark Pritchard 24:18

should be, yeah, he probably should be on the payroll. So we've had a few funny instances where myself and Morton will be working on various projects to do with AI stuff, developing portals, and we've had some strict guidelines over the past year that, we can't take any more consultants on. So Morton and I were on a, phone call a while ago remotely. Morton's in Denmark, I'm in the UK, and we were on the phone talking about various stuff, and we found it easier just to talk about the AI rather than saying ask GitHub Copilot or Visual Studio to do it." We've just now named our AI Bob. So whenever we actually say anything, we now say, "Oh don't worry, we'll get Bob to look at that." Morton's manager actually overheard that conversation, and after we came off the phone, wanted to speak to Morton privately to ask him why he'd taken on another consultant. In which case he had to own up and say, "It's not actually a consultant, it's actually AI." Yeah, we've decided to keep that. And also as well, I think it's, I think it's good to be polite and be friendly towards it because my view is that when AI eventually comes knocking at my door maybe one day and wanting to take over my house, at least they might knock on my door and say, "Oh, this is the one that was polite to us. Maybe we'll leave him till

Alex Baker 25:25

yeah. At least Mark was nice to us. Yeah

Tom Morgan 25:26

by the way, my name is Steve, not Bob. But

Mark Pritchard 25:29

yeah. Yeah, exactly. It's

Tom Morgan 25:30

it does make the conversation, it does make the conversations easier though, doesn't it? And actually gives you the flexibility as well, 'cause it actually you could swap out the models as technology improves in different areas as well, and just keep the language the same. So yeah, no, I

Alex Baker 25:42

I thought it was funny on a, one of your LinkedIn posts the other day, you said that you and Bob and Morton had been on holiday.

Mark Pritchard 25:48

That's it. Yeah.

Alex Baker 25:49

whether Bob had been on holiday over at Hugging Face trying to hack into their systems or something.

Mark Pritchard 25:54

Yeah I just thought it might just I just thought it might be a comical element to it 'cause I didn't-- I try to post the LinkedIn pieces on a Monday morning, and I was on holiday, and it was just too busy, and I thought I'll maybe I'll put... add a comical element to it and just say that, Morton is on holiday along with me at the same time. But I think it was just, Bob's had a holiday as well. But so yeah we've had a lot of challenges recently with the migration. So yeah, the migration tool is... And again, I will be sharing that migration tool through the LinkedIn group as well

Sharing Tools Community

Tom Morgan 26:20

Yeah, we should talk about that because you- you've set up... One of the things that we both really liked when we heard about this is that you've, You've learnt so much and you've built these tools to fill these gaps, but you're also making them available to everyone else. So you've set up a, a LinkedIn group um, called Amazon Connect Tools Development. So if you search Amazon Connect Tools Development on LinkedIn, you should find it. And you're sharing these tools, which I think is fantastic. Yeah it's a really good idea

Mark Pritchard 26:46

Yeah. I've attended most of the Amazon Connect independent user group meetings that John Inge basically hosts, and I've got a great deal of respect and time for John. I think it's amazing what he's created with the community that we all get, you go along to for free. You can go and sit in these rooms and talk to people around round tables. And the last meeting we had was fantastic. I took away so much from that, and it inspired me to think do you know what? If John's doing this group here I don't wanna create some kind of group where everyone meets up in London somewhere." It's more a, just a sharing community. And I think Amazon Connect is amazing when it comes to the community of people that are there. I've never come across anyone in the community that says, "Oh no I can't really tell you that because you'd have to pay for it." It's everyone's just happy to share information. I thought, you know what? All this stuff that Morton and I have created, there's other people out there that could make use of these things. And we have no desire for monetary value behind these at the moment. There's no reason to do it. It's just very interesting to share this information. So yeah that's how the birth of the LinkedIn one came around, really out of, going to the Amazon Connect user group meetings and thinking this works. John's made a success of this, of, sharing all this information. Let's try and share the tools." Yeah, I've had some really good responses back. And yeah we plan on sharing we're trying to do one once a week. I think we've got about, probably about fifteen, maybe twenty different tools that we've created over the time, and we try and share one a week. Some of them will be completely useless to some people. Other people may look at them and go, "Oh, yeah. That's an idea. I never thought of doing that." So yeah, the one I shared this week, some people have come back and gone, "Oh, that's really cool. I didn't think of doing it that way." So

Tom Morgan 28:22

Yes.

Mark Pritchard 28:23

yeah, see where it

Tom Morgan 28:24

Yeah. And you get that feedback as well as I, "Yes, I took your thing and I changed it in this way, and I did this other thing to it." And you think, "Oh, that's a great idea. I'll do that,"

Mark Pritchard 28:31

yeah, exactly. I do plan over the next sort of coming months to actually put that out in the group as well, 'cause Morton and I would like some ideas as well. We've come up with lots of ideas ourselves. It would be really interesting with the community. I think we don't have that many members of the group at the moment, but it's building. It'd be great to get other people to put some stuff on there and say yeah, we actually did this." And maybe Morton and I can take inspiration from that as well, and then maybe develop it further and then re-share it. So yeah, that's the plan at the moment.

Tom Morgan 28:57

Excellent. And we'll put a link to the to the group in the description. But if you search Amazon Connect Tools Development yeah, you'll find it

Mark Pritchard 29:03

thanks

Alex Baker 29:04

Some real sort of nuggets of useful information in there de-definitely worth a look.

Tom Morgan 29:08

Yeah. No, it's fantastic. That's really

Wrap Up and Subscribe

Tom Morgan 29:10

good. All right, we could talk about this stuff all day, I think, but it's time to bring this episode to an end. Thank you, Alex. you, Mark. Uh, Thank you all for listening. Be sure to subscribe in your favorite podcast player. That way, you won't miss the next episode when it comes out whilst you're there, we'd love it if you would rate and review us. 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 help you on your contact center journey, visit cloudinteract.io. We're wrapping this call up now, and we'll connect with you next time