How This Program Manager's Deep Dive Saved a Client Millions from Overbilling

So like, you're asking

OK. Uh, use up the best example on the first question. OK. Um, OK So the, so the end result for this, uh, Situation is that Um, I prevented the client from paying 2 to 3 times of overpayment, uh, which involves multi-million dollars. So what happened is that We noticed that when the client was um billing some of the invoices, they Have like overbilled it. They have either billed it like 2 or 3 times without the system noticing, uh, because currently there is no validation in place saying that if this invoice has been uh invoiced once, it cannot be invoiced a second time. So none of those, um. Precaution or condition is there to prevent overbilling. So Uh, we noticed that there was, um, like an overpayment or there will be an overpayment based on the, um, number in the system. So, what happened is that luckily we have some time before the actual payment actually happened. There were like 2 to 3 weeks before that, so we have enough time to Uh, look into the problem and see what happened. Um, as I stated earlier, because there was no like validation to uh prevent the user from like dual building or triple billing, um, that's why this incident happened. So the first thing we looked into is How we can um Fix this problem. Like the short-term fix would be, first of all, most importantly fixing the number so that they don't get overpaid, but there, we also need to come up with a plan for long-term fix so that the same problem does not happen again. So in order to deep dive into this, um, we had to look into like how to fix the number first. We need to identify Um, what kind of invoices, which invoice were overpaid, which one is not, and we don't want to fix some of the issue, but creating more issue afterwards. So, uh, having checks in place is very important for this process. So, we started by investigating in what Um, what can be done and then which user what is it and then what's the time period that they've done, but we noticed that there are a lot of users and then they, this, these users were literally Uh, sending in invoices all the time like there's no like a specific time or pattern that we can follow or trace and we can't just filter out, oh, it's uh user A that has submitted all these problems, uh, invoice because it comes from literally and like all the users. So we don't have an easy way to find out, um, identify which set of data was having problems. So, we need to like dive deeper by analyzing, uh, like by approaching it with this a different way from Uh, not from the user end, not from where the problem is coming from, but rather we have to, um, get a list of, uh, all the invoice and what the correct amount should be from the user first and then cross-referencing it with what the system is currently having. So, um, with that, we were able to identify, uh, which ones were duplicate and which ones are, should be kept in the system. So with that, uh, extra sheet of Um, information provided by the user, we were able to, um, clean it up, but that is the easy part. So after we clean that up, we have to come up with like a long-term solution to fix, to prevent this incident from happening again. So, because we, we do have a fairly good understanding to the system, so then we, we had different ideas of like how to build it up, but we need to uh pick and choose to decide which one would be the most efficient way and which one would be. Spending the least time with the most outcome. So we were like having a diff, a bunch of different options. We were evaluating based on their um Effort versus uh outcome. And so we were uh prioritizing like different approaches. With um With that, um, some of, we have like a couple of pretty good solutions. Both of them were, um, Very good in terms of uh uh the time required to complete it and the outcome for it. How else,

Oh, I, um, I also work with the engineering team because otherwise we'll be able to build up the solution for that. Um, and then they play a pretty key part in this when we were discussing, uh, the solution. Uh, because they were ultimately they were, they will be the one who is building out this solution, so they are also heavily involved in this, um, decision-making process. And um

Yeah, so at the beginning, like I, I list out like the all the cause and effort um charge and then I brought it to the And so, so what I talked about earlier was just happening within my team. So we come up with like a couple of pretty good solutions and we all think like certain of them are pretty good. So we brought it up with the engineering team, um, and then get their opinion on it and then we realized, um, some of them are actually good solutions, but it requires way more time than what we thought it would be and it turns out, um, the not so good solution is actually Um, the best one in terms of like, um, the cost, like the effort that requires to build out the solution and the outcome of it. And we'll capture like most of the uh scenario. So, um, at the end of the day, we end up going with that solution and then uh we built a, we, we deployed this uh feature to the production environment. And with, in the following couple of months, we run into a lot less of these um double invoicing problem, um, even though there are some of them because the uh solution that we ended up choosing was not the perfect one, but we were able to deploy it within a very short period of time and for all the ones that were missed, it was very easily fixed, uh, with Easily fixed within like a short period of time.

So this whole incident, uh, as I was mentioning earlier, it was 3 weeks prior to the, um, like payment. So the Fixing that like the data fixing was done within 2 weeks and then um so then that prevented them from overpaying. And then, um, to build up the, uh, like the full solution, it took a month which was just 1 week before the next invoicing that's happening and then we were able to capture um 90% of the Invoice, I'm sorry, 95% of the invoice and it only like very little of them uh had to be fixed afterwards. OK,

It prevented 95% of the errors because before there were like um like about a couple 100 of them and after implementing or deploying the the solution, we only have like 10 or 20 or so that we have to fix.