Hi Y'all
I'm having problems with the SFDC integration with Q.
Here is our implementation structure: Case & contact data from SFDC --> Contact Directory in Q --> Survey trigger --> Survey absorbs all case & contact info as embedded data. We have 3 different channels from SFDC to Q to trigger surveys and collect customer feedback on 3 of our different support groups (that serve the same customer base)
Recently, I have seen multiple instances with duplicate survey responses registered for the same case. After my initial analyses I found that customer took 2 different surveys (with diff case #s that I can infer from the distribution data) but the responses are mapped back to one case #. After talking to Q Support, I understand that when a new case (lets call it C2) for a customer (let's say "John") is closed in SFDC and info sent to Q to trigger a survey, Q UPDATES all data fields associated with the customer A, be it contact data or case data. Now what happens if the customer takes the survey which was sent to him for the previous case (C1?); his responses are captured by the tool but they are incorrectly mapped with "C2" case info.
Q says that it is a unique issue that we face in our Org but I can't believe this isn't a common problem. anybody came across this issue and/or can suggest a solution?
Note: I know the option of turning off contact de-duplication may help (which is what Q suggested) --> I understand this may help by maintaining duplicate contact records in the Contact directory with all case info (But to me, this isn't the best solution or approach as this kills the purpose of Contact Directory)
What would be more ideal in my opinion is Q to have a "Operational data directory" that links with the "Contact Directory" on a many:1 relationship. But I don't get the feel that Q has the data strcutured this way.
thoughts? comments?
- Thanks
Page 1 / 1
I hate to say it, but I think you kind of already found your solution. And it's to turn of the de-duplication. The feature exists so that if you get duplicates it updates information so that you don't have to.... I kind of feels like it's working perfectly hahaha.
It sounds to me like maybe a process improvement to me. Maybe the call center is closing cases too early? Not making sure there is a resolution, so now they open two cases too close together? It feels odd (although certianly not impossible) that two cases would need to be created so close together for totally seperate issues.
It sounds to me like maybe a process improvement to me. Maybe the call center is closing cases too early? Not making sure there is a resolution, so now they open two cases too close together? It feels odd (although certianly not impossible) that two cases would need to be created so close together for totally seperate issues.
Thanks for the response Kate. Yes, de-dup might help but there are compromises that must be made if we implement that as a solution.
I heard from Qualtrics support that they are planning to roll out "Transactional data" similar to embedded data, that would resolve this issue. Will wait to see how that works.
I heard from Qualtrics support that they are planning to roll out "Transactional data" similar to embedded data, that would resolve this issue. Will wait to see how that works.
That's awesome, @Divaco! I don't know where I can throw my support behind that idea, but that could GREATLY enhance my transactional survey program. I hope that comes along soon.
Leave a Reply
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.