Episode Transcript
[00:00:01] Speaker A: Hello. Thank you for joining us. Welcome to what Counts, the podcast where we explore real world challenges and opportunities shaping information governance today.
Each episode draws on our experience working across industries, turning proven strategies into practical insights you could apply inside your own organization.
Whether you're navigating information governance, facing a specific need, or simply curious about issues like email management, retention, contract data, or asset data management, this podcast gives you clear, actionable perspective on what truly counts in building strong, sustainable governance practices.
This is Lee, and in this episode, Moir and I are picking up right where we left off.
We took a look at an AI generated scenario, a customer support escalation workflow, and we picked it apart.
We found that the promise was big, but the assumptions were even bigger. Messy data, disconnected systems, security gaps, hallucinated answers. The AI told us it could do it all in 10 minutes. We weren't buying it. I was, but Maura fixed that one
[00:01:12] Speaker B: a little bit by the end of the episode. You weren't.
[00:01:15] Speaker A: I wasn't buying it after that either.
So where would you like to go with this one?
[00:01:22] Speaker B: So I'm with you. We didn't buy it. The AI's assumptions were that there was no messy data.
All the systems talk to each other. Everything was, and everything that that AI needed to complete that workflow was available to it and it was accurate, it was consistent, it was reliable, and it could make all the decisions.
[00:01:43] Speaker A: But already set up.
[00:01:46] Speaker B: Yes, because. Because a customer support escalation workflow is a relatively straightforward thing. Right? You, you have a customer, they're calling with a problem and you try to answer it with first level information. You know, yes, you're right, there was a power, an Internet outage for two hours last week. I'm sorry.
And then they say, well, we want a credit on our bill. And maybe your customer service rep, your first tier rep is authorized to say, well, okay, what I can offer you is, I don't know, X. I can offer you $20 on your bill because you asked. They wouldn't offer it 10. They're not, they're not handing it out proactively. Maybe they offer it or they say, no, I'm sorry, but your contract with us says you're not entitled to that.
[00:02:38] Speaker A: You waited on the phone for two hours, so we'll give you something, but.
[00:02:43] Speaker B: Or they say, no, actually the outage has to be for more than 72 hours before you're entitled to any compensation. It's in your contract. And then the customer says, well, that's insane. I never signed that contract.
And so then you're in your workflow, you have to be able to find the contract that they signed.
And in some cases it was a verbal signing.
Because sometimes when you're talking to a cable company, for instance, the, you get a recorded line at a certain point and you say, this call is now being recorded. And I need you to affirm these things before we can put this order through. Do you understand xyz?
And the customer says, yes, yes, yes, because they just want to get the order done. They're not really, maybe they're not paying attention.
Maybe the, maybe the recording actually says, you affirm that we've sent you all the terms and conditions and you've reviewed them and it doesn't actually say in the call you agree that you don't get any compensation until there's been an outage of more than 72 hours. That is most likely what is happening.
So those are pretty straightforward from a workflow perspective. There's not a lot of variation there.
But when you're trying to make it an AI driven workflow, the AI has to have all the scenarios, it has to have what are the thresholds and what are the decision points.
And it has to have access not only to, these are my decision points, this is my response is, but also that next level, I gotta go find the contract. And do I have access to the contract? And is the contract the right one? Is it the one that they signed or verbally agreed to, or is it just the newest terms and conditions? And do you know when those terms and conditions went into effect?
Because if they went into effect after this person signed up, maybe it doesn't apply to them, but maybe it does. So that's where the, the assumptions start to break down. All right, so what I came away with from this exercise was it's aspirational to be able to get to a point with, with something as simple as that workflow, because that's not a very complex workflow and it's, and is it achievable?
So not just aspirational, but actually achievable. And the answer is yes, it is. It is achievable because all of that data was collected at some point. You have the customer name and identifying information, which is often a phone number. So then if you change your phone number, which used to happen more often before everybody was just using their cell phone, that they never gave up. But when you moved states before cell phones were ubiquitous, your area code changed, your phone number changed, you might have changed. We changed phone numbers when we were kids because living Outside of the District of Columbia, there were some local phone numbers that were that made it long distance to call DC and there were some that made it local to call DC and Northern Virginia and that area of dc, Northern Virginia and Maryland. Right outside the District, people worked back and forth there you went to school, back and forth there you were, back and forth every day over the bridge. So having to make it long distance to call was expensive, but getting the phone number that made it local was also expensive. So you had to decide which was more. And your phone number could change a couple of times.
[00:06:23] Speaker A: Well, we just recently got rid of our house phone and you can't believe how many pizza joints had the house phone number, not our cell phone number. So. Yes.
[00:06:32] Speaker B: So now they don't know who you are or where you are exactly. Their customer system set up on your house phone.
So your customer data is oriented in one way. Changes to customer data come in haphazardly and you don't know. And did that system that collects the new phone number, is it attached to the customer service line? Maybe, maybe not. Is your old phone number the one that was attached to that verbal. I agreed to these terms about the 72 hour outage thing, probably because it was a transaction where you had to agree to it. So the AI doesn't know that. It knows that you told me your phone number is X or I captured it on the incoming line. It said you called me from, you know, 301-555-1212.
I don't have a contract that says 301-555-1212, which that's a problem because now I can't prove that you, the customer agreed to this, but you have service, so you must have something.
And then that's where you get the hallucinations. It just starts making. It could fill in that gap by saying, well, you must have done. And here's the most recent set of terms. So these are the ones you agreed to. And then your customer fights with you. So the, the fix to this is managing your data in a painstaking way. And it starts with data objects. And when I'm talking about data objects, it comes from the world of entity relationship diagramming and database design.
But I don't wanna talk about that level of technical detail. What I wanna talk about is intuitive logical groupings of data in just our scenario that we've been talking about. Right?
There's data about the customer, which includes their changing phone numbers over time. There's data about the contract which includes today's terms. And conditions and past terms and conditions based on the date that the customer signed something or started their service, or did they get a deal and then the deal changed because that happens all the time with cable.
So those two sets of data exist, and the connector between them is usually like in theory, conceptually, here, not talking about data systems, but in theory, the connector is a customer ID and a specific version of the contract and a date at which it was agreed. Right. Okay, so three key pieces of data. Who's the customer, customer id, what contract did they sign? That's the version and the date they signed it.
Because those with those three pieces of data working together, the AI, in theory, again, conceptually, should be able to solve this problem and say, here are the terms you agreed to. Oh, you're right. When you signed this, we were having a deal that said we were guaranteeing 99.99 uptime. And you do get a credit, for example. We just don't give that to very. There's not very many people that were. That got that deal. It only lasted 12 hours, congratulations, we'll send you $20, that kind of thing.
But you have to have all three of those pieces of data be accurate and be connected.
And that's a simple example. It's three pieces of data.
[00:10:09] Speaker A: So where's the object?
I'm still waiting for the punchline.
[00:10:14] Speaker B: The object is over here. We have a record about the customer. That's one object. And it has not just their id, which might be their phone number, but it has their name because they're calling in and saying, I'm so and so, and they're calling in from a different phone number, but they have to be able to tell you, this was my phone number when I did it before.
Or you have a history of they originally had this other phone number, but now they have this new phone number. And we know it's the same person, we know it's the same customer. That's one object is data about the customer. The second object is data about the contract, which is we have a contract and it has these terms.
And the terms are effective depending on different things, because.
So the terms could be effective based on there's a deal, and it was only effective in these, you know, in this window. So then you need to know what was the date they signed it to know if it was effective. But the object about the contract has all the terms that have ever been effective and that are still in effect with some customers.
And then the date of the signing is kind of a standalone piece. But it's really important because it ties the other two together.
So that date thing takes you from the contract object as a set of terms to a particular instance. And that new object is Lee, the customer with his new phone number, with his old phone number signed this version of the contract with this special deal term on this date.
And that is a new object which is an instance of a specific contract signed. Like executed agreement. Even if it was verbal, it's an executed agreement. Those are three different objects that are connected in some way or they're not at all connected. If you can't get to. How do they come together in that. In the third one.
So.
Okay.
[00:12:16] Speaker A: Yep, I'm good.
[00:12:17] Speaker B: Okay. All right. And that is a relatively simple example, but. Yeah, but it's the same logic goes forward. So I think one of the times we talk, one of the other things we've talked about a few times is keeping track of that customer is a challenge for almost every company. Any company that has more than one thing that they do, it is hard to keep track of that customer.
And one of the reasons it's hard is because you've got different systems across the company and different groups that carry out different functions with the same customer. So, for instance, in our cable example, you've got a billing group. And their job is to know where is that customer? So I can send them a bill because we need money, right? That's their only job. How do I get the bill to them?
But there's also, let's say, an installation group. And they have to know physical address, and they have to know the time of day, and they have to know what equipment was ordered by the customer and when that equipment was upgraded, because they have to come back and fix it.
That's a different system because that's a work order system, send people out and that. Typically, work order systems are organized by date.
Today it's by like, by date and person. Like, send the first tech to these six houses to do these six installations, or these six installations plus two more repairs or something. And they're scheduling what is this guy going to do on this day and what equipment does he have to take with him? And that is a whole that is all separate from the customer. It really isn't about the customer at all. The connection is the address. And they probably have to get a signature. So probably they're going to ask you your name, but your name might be on the order, and my name might be. I might be the one who's home and signing.
So it's not A good connection.
Then you go back to the customer, to the customer billing group and they need to know that you got the new equipment so that they can bill you correctly.
They also need to know if you turned equipment in so they can stop billing you. And I know from not my experience, but my sister, that if they don't register your return of one set top box correctly, they will continue to not only charge you for it, but also tell you that you owe them a set top box for months, basically until you move out of the house and stop having cable could go on for years.
For years.
So while those three objects of customer data, contract terms and the instance of the contract are pretty straightforward, then you get all these other ancillary pieces.
So I know we've been through a lot today. Just in this episode, I don't want to start talking about what you have to do to connect, but I do want to just introduce the concept, which is about metadata mapping.
Because each of those objects, as we're talking about them, as there's a collection of data about this customer, there's a collection of data about the contract terms.
Some of that data is metadata, which means it's data about the object.
And it tells you things like what's the customer id?
That's the key. All the other data about the customer, it has to be under a single customer id, for instance.
And next time, what I want to talk about is when you have that concept of customer id, counterparty id, but you've been storing it in the billing system and the work order system and the contract management system, and maybe you have more than one of those.
What that can get you to is a lot of duplicates and a lot of records that are about the same person. Or if we take it out of the world of cable, the same company, the same counterparty from a contract management perspective.
And now you've got three copies, seven copies, 10 copies. Because even inside some of the systems you might have two or three or more.
And so next time we're going to talk about a reconciliation project to figure out what are the real counterparties and what all these different representations of them in the different systems, how do we reconcile and bring them together?
[00:17:27] Speaker A: Well said.
If you have any questions, please send us an email at info trailblazer.us.com or look us up on the web at www.trailblazer.us or check out the Learning Academy at www.trailblazer learningacademy.com no us in that one.
Thank you for listening. Please tune into our next episode. If you like this episode, please be a champion and share it with people in your social media network or like or subscribe to the podcast. That's always nice. As always, we appreciate you, the listeners. Special thanks goes to Jason Blake created our music.
[00:18:12] Speaker B: All right, I have a post script I'm going to add here. Instead of just saying goodbye, I tried
[00:18:17] Speaker A: to keep moving so that you could see that I didn't freeze the.
[00:18:22] Speaker B: The collection, the. The reconciliation that we're going to go through.
The reason it absolutely has to be done if you're going to use AI is because the AI will fill in the gaps with no knowledge.
A person can fill in gaps with knowledge. They can look at three records that relate to the same entity and say, oh, yeah, I remember when they changed their name. Or oh, yeah, obviously we just forgot to put the period at the end of inc.
But a computer will say those are two different things.
And so, absolutely, this activity of reconciling your messy data is a critical step in preparing for effective use of AI.
[00:19:08] Speaker A: Yeah.
[00:19:09] Speaker B: Just one step along the way.
[00:19:11] Speaker A: Consistency is key.
[00:19:13] Speaker B: Yep. All right, so until next time, thanks.
All right.
