Multi-touch programs
When answering to requests for feedback, respondents might have had multiple touchpoints (units) with a company. Those touchpoints often overlap, and can influence each other in ways that can be difficult to perceive. For example:
-
A retail company might allow products to be purchased from one location and fulfilled through another, such as when buying online and picking up in-store.
-
A financial services company might have 5 or 6 individual associates involved in the various stages of a mortgage loan assessed by a single survey response.
-
A hospitality company might want feedback from its franchisees, who are hotel owners. Since a franchisee might own multiple properties (units), relationship feedback is attached to multiple units.
-
B2B programs might have surveys associated with both an account hierarchy and a product or support agent hierarchy.
-
Airline companies might survey about flight experiences, where every flight is tied to multiple flight attendants, and flight attendants from the same crew could report to different managers.
-
A hospitality company might want to evaluate its facilities within the hotel (such as restaurants). The questions for the restaurants are the same (such as OSAT with the restaurant), so the company wants to aggregate these questions to see reports about specific restaurants. For more information about this specific use case, see Sub-records.
Designing a multi-touch program allows companies to capture feedback about all touchpoints, and reinforces the right customer-focused behavior at every step along the customer journey. Executives can lead this strategy with a complete view of the organization, and work to ensure that the whole organization is aligned with the customer experience responsibilities, goals, and success metrics.
Use the following guidelines when planning a program with multiple touchpoints.
Questions to ask your company stakeholder
When planning a multi-touch program with your company stakeholder, consider asking the following questions:
-
What are the multi-touch use cases?
-
If customer feedback is captured for each of these touchpoints, what systematic changes would the insights drive?
-
Who is responsible for closing the loop with the customer?
-
Do all interactions along the customer journey occur within same hierarchical structure? For example, are all units call center agents, or are they a combination of sales, services, call center and account management representatives?
-
Are the touchpoints in the customer journey part of different hierarchical teams? For example, are there multiple agents handling the same call, but working under different managers?
Impacted areas of Experience Cloud
The following table describes the areas of Experience Cloud impacted by multi-touch programs.
| Area | Item | Consideration |
|---|---|---|
|
Integrations |
Invitation data |
Include unit information in the invitation file. For more information, see Invitation file, below. |
|
Survey |
Survey elements |
Remember that survey questions should capture the experience as a whole, not an individual in that customer journey. Each score given in the survey applies equally to all units associated with the record. For more information, see Surveys. |
|
Alerts |
Alert handling |
Each response can trigger only 1 alert. Only the primary unit is listed as the owner of the alert. Experience Cloud defaults to Unit ID as the primary unit field. Determine who should be responsible for closing the loop with the customer. For example:
For more information about alerts, see Alerts. |
|
Reporting |
Data access |
A user with access to any unit associated with a record will see the responses. For more information, see Data views. |
|
Reporting |
Unit or Unit group related calculations |
Records are double counted when making a unit split because the record is associated with both units. This happens only when associated records with units in the same hierarchy using a multi-valued unit field. You might see unexpected results in reports when using calculations involving multiple units or unit groups. For more information, see Units and Unit groups. |
|
Reporting |
Use of multi-valued unit fields |
When using multi-value fields in the Control Panel and Ranker reports, all stored units appear. For more information, see Configuring Multi-touch units. |
Multi-touch approach versus sub-records
Consider whether you should use a multi-touch approach or configure sub-records. As described above, a multi-touch approach allows an individual record to be associated with multiple units, which tracks the entire journey as a single event. Multi-touch also treats every question as being associated with that single journey. Using sub-records, however, associates different questions in the same survey with different units, which leads to a different way of seeing the data via reports. For more information, see Sub-records.
Multiple unit fields versus multi-valued unit field
Using multiple unit fields enables you to store different types of units, and filter reports by those units. For example, a contact center survey might be associated with the account agent and the call center agent.
Using a multi-valued unit fields are more flexible in that they can accept multiple values. For example, a call center might have several different agents associated with a record. For information, see Multi-valued fields.
Anonymous surveys
Multi-touch programs encounter challenges with anonymous surveys (also called feedless surveys). If a record is associated with more than one unit, you might have difficulty determining which unit from which to pull unit data field information. For example a surveys might be associated with both a store and product. For more information, see Anonymous surveys.
Organization file
All units must be represented in the organization file. For more information, see Auto Importer Processors.
Invitation file
For every record to be sampled, all units must be in the invitation file. You can pass these units in the invitation file in several ways, as described below. For more information, see Inviting.
Separate columns
With separate columns, each column represents one unit associated with the record to sample. This allows for maximum flexibility, since some records might need only certain units associated. For example, a call center survey might need to be associated with accounts and agents:
| Record ID | Account ID | Agent ID |
|---|---|---|
| R1 | U01 | U03 |
| R2 | U02 |
The drawback to this approach is in maintenance. When you need to add new units, you must create new fields and integrate them into reports.
Single column
With a single column, all units are listed, delimited by commas. Consider this approach only when no differentiation between units is needed. For example, a call center survey tracks all agents for the same call, but makes no distinction in the agents' roles and responsibilities:
| Record ID | Agent ID |
|---|---|
| R1 | U01 |
| R2 | U01, U02, U03 |
A combination of separate and single columns
With this approach, you apply some distinction between the units listed in separate columns, and no distinction for units in a comma-delimited column. For example, an airline might have multiple flight attendants sharing the cabin services, while each flight might also have a flight lead and a purser:
| Record ID | Flight attendant ID | Flight Lead ID | Purser ID |
|---|---|---|---|
| R1 | U01, U02 | U03 | U04 |
| R2 | U01, U05 | U05 |
Lookup table
If you are using a high number (hundreds) of units, consider using a lookup table. For example, a hospitality company might want relationship feedback from its franchisees, where a franchisee might own multiple properties, and a property might be owned by multiple franchisees:
| Owner ID | Property ID |
|---|---|
| O1 | P1 |
| O1 | P2 |
| O2 | P1 |
Note that with a high unit count, some reports (such as Ranker reports) might be slow to load.
For more information, see Lookup tables.
Scoping
When scoping the effort to implement a multi-touch program, plan 50 hours for the initial implementation, and 3 hours per year for incremental servicing changes over time.
