How to track follow up cases along with original service requests in Pega 6.x/7.x
We are using Pega CPMHC 7 with Pega PRPC 6.2 sp2. We have Categories and intents defined for the CSR Reps. Each intent has its own process flow.
We have a requirement as follows:
1. Sometimes users may call a month after a intent case is resolved (may be 5% of the total cases) and mention that the issue was not resolved or they did not receive the letter & so on. In such a case the CSR creates a new case under a new interaction today for the same member
2. Business wants a way to link the original intent case with the new intent case & extend this functionality to subsequent cases of same type (So more than 1 case can be lined to the original case)
3. Business also wants to see the history of all such linked cases in the latest case.
Our proposed solution:
We are using Pega CPMHC 7 with Pega PRPC 6.2 sp2. We have Categories and intents defined for the CSR Reps. Each intent has its own process flow.
We have a requirement as follows:
1. Sometimes users may call a month after a intent case is resolved (may be 5% of the total cases) and mention that the issue was not resolved or they did not receive the letter & so on. In such a case the CSR creates a new case under a new interaction today for the same member
2. Business wants a way to link the original intent case with the new intent case & extend this functionality to subsequent cases of same type (So more than 1 case can be lined to the original case)
3. Business also wants to see the history of all such linked cases in the latest case.
Our proposed solution:
- In the Member 360 screen of the interaction, we have a Recent interactions tab where we display the last 30 cases for the member (Open or closed)
- We could provide a button to create related case on each of the eligible cases.
- On click of the button, we will create a new intent of the same type & link it to the selected intent (using OOTB link activity)
- For a child case, we will not display the button for creating a linked case as we don't want a chain of linked cases - we just want to be able to link the original case to multiple cases.
Business is not very happy with this & are looking for something more robust & supported by Pega. Could you please let me know if Pega 7 would be able to do this in a better way (as we have plans for upgrade soon) or is this the only solution possible whether we implement in Pega 6 or 7?
Pegasystems Inc.
US
Hello Nikhil,
I'm not sure I follow, you want to link a specific intent item, but not the older interaction? Are you looking to duplicate the old intent in the new one? And when you say see the history, just that item A was linked to B and to C, or a unified view of all the history items in the database for all of the linked intents? I don't understand why you wouldn't want to chain them if it was work coming off the original intent failing to meet the customer's needs. What if someone calls back in a month about case B, wouldn't you want to chain that? Or at least spin off a child for the work? I don't know of any out of the box functionality to do what you're talking about, but you should be able to implement it in any number of ways. It's hard to suggest an idea for how best to implement something that your business would be happy with without understanding more about what their expectations. If you can give us an idea of what sort of design they would be happy with, it would be easier to suggest what you'd need to do to get there.
Thanks,
Mike
Ai4Process
GB
Q1: I'm not sure I follow, you want to link a specific intent item, but not the older interaction?
A: That's correct, Mike. Let's say an interaction I1 is created for which we also created an intent SR-1 & resolved both I1 & SR1 on 1st of Dec 2015. Now the member calls back on 1st of Jan 2016 & says the issue was not resolved. Currently we create a new interaction I10 and a new intent under it SR-10 but there is no way to report that SR10 is a follow up on SR1. That's why we want to link SR10 as a follow up case of SR1 (Don't need it to be a child case)
Q2: Are you looking to duplicate the old intent in the new one?
A: Not really. We initially discussed about prepopulating data from old intent to new one but decided against it & want the user to enter all the fields again as though it were a fresh intent.
Q3: And when you say see the history, just that item A was linked to B and to C, or a unified view of all the history items in the database for all of the linked intents?
Q1: I'm not sure I follow, you want to link a specific intent item, but not the older interaction?
A: That's correct, Mike. Let's say an interaction I1 is created for which we also created an intent SR-1 & resolved both I1 & SR1 on 1st of Dec 2015. Now the member calls back on 1st of Jan 2016 & says the issue was not resolved. Currently we create a new interaction I10 and a new intent under it SR-10 but there is no way to report that SR10 is a follow up on SR1. That's why we want to link SR10 as a follow up case of SR1 (Don't need it to be a child case)
Q2: Are you looking to duplicate the old intent in the new one?
A: Not really. We initially discussed about prepopulating data from old intent to new one but decided against it & want the user to enter all the fields again as though it were a fresh intent.
Q3: And when you say see the history, just that item A was linked to B and to C, or a unified view of all the history items in the database for all of the linked intents?
A: The linking will automatically appear in this history. WHat we are talking about here is displaying the history entries of the original case in the history section of the linked cases (& possibly history form other linked cases of the original case too)
Q4: I don't understand why you wouldn't want to chain them if it was work coming off the original intent failing to meet the customer's needs. What if someone calls back in a month about case B, wouldn't you want to chain that? Or at least spin off a child for the work?
A: If I were to chain - that is link SR1 to SR10 & then link SR10 to SR20 (a second follow up case) then my reporting would have to chain thorough all the links to find the count of repeat calls for the original case. If I just linke SR1 to both SR10 & to SR20 then I could easily get the count as 2. AS mentioned in Ans to Q1, we don't need a parent child relationship. Moreover if the original case is still open then user would continue with that instead of opening a new linked case .
Q5: If you can give us an idea of what sort of design they would be happy with, it would be easier to suggest what you'd need to do to get there.
A: I am also trying to have further discussion with the BAs. Our current requirements have come from SAs who are interacting with the BAs. But the crux of the requirement is that they need to track the follow up cases as linked cases & have a count of how many such linked cases are being created & improve processes to reduce these follow ups.
Pegasystems Inc.
US
Nikhil,
Thanks for the clarification.
Nikhil,
Thanks for the clarification.
Should the link reside on SR1, SR10, or both? Presumably SR10, because that's the open case where work is being actively done. That's also why chaining makes sense to me (SR20 is the open case, finishing work started in SR10 last month, which did more work on the item started in SR1 two months ago), although it definitely makes reporting significantly more challenging. Certainly, if you have a list of keys for the linked items, you could make a custom history section that calls a report displaying history for the current item and all the linked items. I'd use the OOTB history display/underlying report as a jumping off point for customization. I don't know what the OOTB link activity you are using does under the covers, but if doesn't meet your needs, you may need to build your own. If it were me, I'd be looking at a double linked list design (so opening SR1 tells you that SR10 is already out there and opening SR10 tells you that SR1 is related), with a one to many design (arguably, if you don't do chaining, when you need an SR20, you'd want to link it to SR10 and SR1 so that when the customer calls and says "I had a problem with SRx" the user of your application has access to full information). If the count resides only on SR1, how do you differenentiate that from SR10 and SR20, but keep is similar to SR21 (a brand new interaction with a different customer, which spawns SR31, etc.)? What you are looking to do has a lot of details to take into consideration. I'd look for ways to keep things as simple as possible (for such a complex design). You may need to think about link tables/objects that hold the shared information so you can report off of that and just point to one of those or something.
And all of this is based off the assumption your customer calls and says "I am unhappy with item SRx" and not "I'm unhappy with the outcome of <vague description of the purpose of the intent> at some point in the past" in which case you'll need to search the item(s) up and factor all of that additional complexity in. Hopefully your conversation with your BAs will result in some actionable user stories.
I hope that helps.
- Mike
Pegasystems Inc.
IN
Hi Nikhil, Good Morning!
>>> an interaction I1 is created for which we also created an intent SR-1 & resolved both I1 & SR1 on 1st of Dec 2015. Now the member calls back on 1st of Jan 2016 & says the issue was not resolved. Currently we create a new interaction I10 and a new intent under it SR-10
- would it make sense & feasible to Reopen the old interaction case (I1 & SR-1) instead of creating a new (I10 & SR-10) to investigate the request?
Hi Nikhil, Good Morning!
>>> an interaction I1 is created for which we also created an intent SR-1 & resolved both I1 & SR1 on 1st of Dec 2015. Now the member calls back on 1st of Jan 2016 & says the issue was not resolved. Currently we create a new interaction I10 and a new intent under it SR-10
- would it make sense & feasible to Reopen the old interaction case (I1 & SR-1) instead of creating a new (I10 & SR-10) to investigate the request?
Please share your thoughts/comments, Thank you!
psahukaru
Ai4Process
GB
We had discussed exactly the same question. I think we should not reopen the I Case or the S Case because:
1. Interactions are meant to symbolize the phone call (or the correspondence) & should not be reopened once the interaction ends.
2. Reopening a S Case is a possibility but presents lot of challenges
- Where in the flow would you take the S Case after reopeneing it. If it has multiple assignments then system would have to decide where to make it land
- There are usually lot of issues with reopened cases (which I found out first hand during one of my previous projects which was not a CPM project btw)
3. You will be overwriting all the data on the existing S Case which is not good from an audit perspective
SO we decided to implement case linking by creating bidirectional linking b/w the new S case & the old one. If reqd we have also provided the users an option to link the new S Case to the old interaction as well.The OOTB activity we call for linking is CALinkObjects
Hope this helps.