Target release
Epic
Document status
DRAFT
Document owner
Designer
Developers
QA

Goals

  • Migrate help sites supported by EMEA (Jo Lotey and Laura Beasty) from disneysupport.zendesk.com to shopdisney.zendesk.com

Background and strategic fit

As part of the DTCR (Direct to consumer retail) effort, we are looking to streamline agent workflows and provide more flexibility for shopDisney international and shopDisney domestic teams to collaborate and provide extended coverage. As EMEA also supports support.disney international contacts, we also need to move these workflows so EMEA agents are only logging into a single instance of Zendesk. 

Assumptions

CRM

  • The following support brands will be moving (This will ultimately be up to Dawn and Jo for how they set things up)
    • Disney Tickets
    • TBD
  • The following support brands will NOT be moving:
    • Disney Life
    • ...
  • Dawn, Jo, and Laura will work to design the desired agent experience in shopdisney.zendesk.com including forms, workflows, triggers, automations, etc. 
  • Once complete, we will deprecate/remove the residual EMEA workflows, brands, triggers, etc. 

Help Sites

Phase 1:

Overview: 

For phase 1 we will look at migrating CRM first which means that email forms and live chat will need to point to the appropriate forms/departments on shopdisney.zendesk.com and the phone widget/numbers will need to be updated to point there as well. 

The Plan:

  • Live chat
    • Can load new instance widget on the existing help center
      • Live Chat ID
      • We currently use 1 live chat script across all sites
      • When CRM moves, we'll need to handle loading a new live chat script on support.disney.com in the appropriate categories/sections. 
    • Chat department names setup and communicated
    • Structure of tags per brand
  • Email
    • 2 options: 
      1. Use request api to send tickets into shopdisney.zendesk.com
        1. Less risk as  
      2. Redirect from support.disney.com to new form on shopdisney.zendesk.com (this one is jenky)
  • Phones
    • Does EMEA use Talk? 
    • If so, they'll need to get licenses
  • JSON Settings:
    • We'll have to update the JSON settings per language with:

"chat_department": "EN_GB-Disney Store",
"phone_department": "EN_GB-Disney Store_Phone",
"chat_tag": "chat_en_gb-disney_store",
"widget_color": "",
"ticket_tag": "disney_store",
"online_web_form_tag": "web_en-gb_disney_store_help"


Phase 2:

Overview:

Phase 2 will be the full migration of help sites to shopdisney.zendesk.com so guest facing content can be managed in a single place for all supported brands. This will include support.disney.com international content, Disney Tickets, shopDisney UK etc. 

Considerations:

  • Enterprise Guide will be required for this migration. 
  • Need to support regional content for both help.shopdisney and support.disney.xx
    • This includes regional legal footers. We will need some sort of geo-targeting (Tredir) to determine location of guests in order to display the appropriate legal footer. 
    • Current implementation for support.disney is to use the language selector as a "region" selector. The trouble we get in here is that this is based on browser language, not physical locale so we are likely displaying the incorrect footer for some guests. IE - French Canadians with their browser language set to French (fr-ca) are being directed to the France French (fr-fr) site which will display the France footer, not the Canadian footer. 
  • We have 2 options for support regional content:
    1. Single site using geo-targeting for region and language selector. (Similar to support.disney.com)
      1. This simplifies content management by allowing the same article with regional/language variations to be managed in one single brand. 
      2. This does assume that the language people speak corresponds to the region they are in which can be a flaw.
      3. With this approach, we'd need to implement geo-targeting so we can identify where guests are from and display the appropriate legal footers etc. 
    2. Separate brands for each .xx site. 
      1. This means the content for each site will be managed in each separate brand and overlapping content will need to be duplicated in each brand. 
        1. A potential solve for this could be using Zendesk's content block feature which is currently in a closed EAP. https://support.zendesk.com/hc/en-us/articles/360039122174-Managing-content-blocks-Guide-Enterprise-
      2. This approach will likely mean we do not need a geo-targeting solution as we can add the appropriate legal footers to each .xx site rather than juggling footers on a global site based on geo-location
      3. This also allows for regional flexibility should there be design differences. 
      4. The downside is if all designs are the same and changes are in sync, site/layout changes need to be made in multiple code bases. 

Recommendation:

Current recommendation (as of 9/16) is to split the sites into multiple brands based on region to align with broader Disney and shopDisney branding. (IE - .fr, .de, .it etc) 

Pros/Cons for splitting into multiple help site brands (IE - .eu, .co.uk, .fr, .de etc):

Additional Multibrand pros/cons listed here: Multibrand

ProsConsNotes
Maintain current branding and domain structure of .eu, .fr, .de, .com etc.More domain names/certs to manage

More flexibility for individual brand theme control (IE - .fr can have different theme than .com etc, menu for each regional site can managed easier )

Common article content will need to be managed in each brand. (IE - forgot password instructions)
More flexibility for contact channel controls - Each region can have their own channel strategy and setup. More releases if there are global site updates.
Reporting on traffic patterns and content for each .xx domain will be easier.

Easier to manage regional footers (IE - don't need to juggle which footer shows based on language/region and don't need to have each regional footer translated to all languages


The Plan:

Other considerations:

  • Device picker


Big factor with this migration is that Curtis can't develop against the stage box at all as he cannot get the environments running.


Requirements

#TitleUser StoryImportanceNotes
1
2    

User interaction and design

Questions

Below is a list of questions to be addressed as a result of this requirements document:

QuestionOutcome
What is the expected Guest experience? Will it be the same help site styles, just in different languages? (For both shopDisney and all other supporting brands?) Will the chatbot be on both NA and international sites?

Not Doing