Introducing the XM Directory Task

KatharineSKatharineS Seattle, WACommunity Administrator Administrator

Introducing the XM Directory Task

Last week, we introduced a new feature, the XM Directory Task. This feature is replacing an existing one called the Distribute Survey Task.

What is this feature for?

  • Studies that involve multiple surveys that must be sent one after another. For example, if each respondent needs to get a post-test survey exactly 4 weeks after they completed the pre-test survey. (There are lots of timeframes you can choose, of course - just an example.)
  • Saving contact information to a list. If you also have XM Directory, you can also use this task to save transactional data to a contact.
  • Send out surveys to a transaction created for a contact without overwriting the contact-level Embedded Data.

Who gets access to this feature?

Everyone! Despite the name, this feature isn't just for those with XM Directory in their license.

What will happen to my old Distribute Survey tasks?

We will not remove any existing Distribute Survey tasks from your surveys. You'll still be able to edit these tasks as needed. However, you can't add new Distribute Survey Tasks to your actions - you'll need to use the XM Directory Task instead.

Tagged:

Comments

  • PavelPavel NorwayCommunity Member Qubie ✭

    Correct me if I'm wrong, but it's still not possible to distribute a survey to a particular transaction?

    The risk with the way XMD and ED currently works is that attributes on a contact in XMD can change after a survey has been distributed, but before the respondent actually clicks the survey link. This is especially important for high-volume call center transactional CX programs, where attributes on contacts in XMD can be overwritten many times throughout one day, but contact frequency settings prevent multiple surveys from being distributed.

  • MsIreenMsIreen FinlandCommunity Member, XMPN Member Superuser ✭✭✭✭

    @Pavel We are facing exactly same issue. Due to this issue, we cannot even deduplicate our Directory. So frustrating

  • AdamK12AdamK12 Bethesda, MDCommunity Member, XMPN Member Guru ✭✭

    Thanks, @KatharineS -- just to be clear, the use case for this feature is to distribute surveys via an e-mail contact list, not for repeated distribution through a site intercept using a cookie, correct?

  • KatharineSKatharineS Seattle, WACommunity Administrator Administrator

    @AdamK12 Correct, this is an email or SMS contact list distribution, not site intercept. No cookies are involved.

    @Pavel & @MsIreen The XM Directory task can be used to add transactional data to a contact. Even if you choose to distribute a survey, you can add a contact and update transactional data. (Apologies if I'm misunderstanding the question!)

  • PavelPavel NorwayCommunity Member Qubie ✭

    @KatharineS said:
    @Pavel & @MsIreen The XM Directory task can be used to add transactional data to a contact. Even if you choose to distribute a survey, you can add a contact and update transactional data. (Apologies if I'm misunderstanding the question!)

    Yes, you misunderstand. A survey is distributed to a contact as a whole, not the transaction that was added with the XMD task.
    Between when the survey is distributed and when the respondent clicks on the survey link, the contact's attributes can be overwritten with new data many times, and survey flow will always set ED from contact at the time the link is clicked, by which time the original data which triggered a distribution and contact creation is already outdated.

    The only solution would be to be able to distribute a survey to a transaction, and/or set ED from a particular transaction, rather than the contact.

    The current implementation makes Transaction functionality in the XMD task effectively useless, since it just highlights what is essentially a giant feature gap which can only be solved by some creative use of Automations in XMD. There is, as far as I know, no way to deal with this through either API or Actions.

  • KatharineSKatharineS Seattle, WACommunity Administrator Administrator

    Hi @Pavel - sorry for the confusion here! To make sure I can address your concerns, I spoke directly to the product team involved.

    Do you see here, in step 9, where you can choose whether to "Save and update embedded data" or "Add as a transaction to the contact info?" When you choose "transaction," this ensures that the contact's attributes are not overwritten, but saved as distinct transactions connected to that contact. This option is available when you use the XM Directory task to update a contact or to distribute a survey. This means you can effectively distribute to the transaction just created, or update a contact with a new transaction without overwriting previous data.

    However, this "transaction" option is only available to customers who have access to XM Directory (not just the XM Directory Task) and who have permission to use the directory. If this option does not appear while setting up an XM Directory task, it is worth reaching out to your Brand Administrator to see if this is an account permissions issue or due to the Qualtrics license you have.

  • PavelPavel NorwayCommunity Member Qubie ✭

    OK, so consider the following scenario:

    1. John calls Qualtrics at 12:00 and Speaks with Jane in Sales.
    2. An XMD task is triggered through a JSON event which adds the call's metadata (including Jane's name) to John's contact in XMD as a transaction, and a survey is distributed.
    3. John calls Qualtrics again at 13:00, and speaks with Susan in Support.
    4. Another XMD task is triggered through a JSON event which adds the 2nd call's metadata to John's contact in XMD as a transaction, but no new survey is distributed due to contact frequency settings.
    5. John finally clicks on the survey link at 13:15, and completes the survey.

    If call metadata is set in the ED block in the Survey Flow, which transaction data will end up in the response as embedded data - the 1st call with Jane or the 2nd call with Susan?

    Unless Survey Flow and XMD functionality has fundamentally changed recently, it will be Susan's data, even through the survey was originally distributed for a call with Jane.

  • MsIreenMsIreen FinlandCommunity Member, XMPN Member Superuser ✭✭✭✭

    I would like to add my 5 cents also on how unclear the transactional metadata is.
    We have a support survey integrated to Salesforce, a survey is sent when a case on SF is closed. if respondent gives low scores, a child case is created automatically. It is to be attached to the original case to follow up on what went wrong there. If there are multiple cases closed for the same person, the case SF ID on the contact in XMD gets overwritten every time.
    So, for example, we have same customer, their case A closed on Monday, Case B closed on Tuesday, Case C closed on Wednesday. We send them a survey invite on Monday with email text asking about case A.
    Meanwhile, the value of the Embedded data field "Case SF ID"on the Contact will be "Case A ID" on Monday, then it will change to "Case B ID" on Tuesday and on Wednesday the value will become "Case C ID".
    On Wednesday evening this particular person decides to give their feedback. They think they are giving feedback for Case A which went really bad, so they give really poor scores. The system creates a child case in our SFDC, parent case to this one will be Case C (as the values have been overwritten). I am not mentioning now all other case attributes that are overwritten in the above scenario.
    I honestly do not see how the transactional fields are solving this issue.

    Correct me if I am wrong here

  • KatharineSKatharineS Seattle, WACommunity Administrator Administrator

    @Pavel @MsIreen I apologize for the confusion here - sounds like you have some pretty specific setups in this case. I’d recommend getting in touch with our support team here so they can better dig into your specific case with you.

  • PavelPavel NorwayCommunity Member Qubie ✭

    @KatharineS said:
    @Pavel @MsIreen I apologize for the confusion here - sounds like you have some pretty specific setups in this case. I’d recommend getting in touch with our support team here so they can better dig into your specific case with you.

    I've had several discussions about our use case with EPS, and the conclusion was that there is no solution. There is a complex workaround involving Automations, but it's not really relevant for us since we have hundreds of thousands of distributions every month via API.

    While not quite the same, I think @MsIreen and I have somewhat similar use cases, and I wouldn't go as far as calling them "pretty specific", because any large-volume transactional contact/call center CX programme will face the same issues.

    The simple truth is, Research Core and XMD were just not designed to handle the demands of large enterprises. That's why I initially started to question the new transactions functionality in the XM Directory task - I just can't see its practical utility, and what problem it's supposed to solve. Transactions as a feature, as it's implemented in Qualtrics now, is next to useless, and a lot of work would be required to actually make it work as an enterprise-oriented feature.

Sign In to Comment