Interaction properties provide the ability to append custom details to your interactions. For example, you might use them to categorize support requests as defect, user error, or enhancement. Interaction properties can also be used as skills. When used in a skill, they help separate questions that require special expertise like Spanish. When displayed within an interaction, the properties panel looks similar to below.
Create and delete interaction properties from the properties list panel. The delete property button will open a dialog box requesting confirmation.
Deleting an interaction property
Configuring an interaction property
1.Property Name – This name will be the label displayed within the Topics page and on forms where the property is entered.
2.Tenant default value - the default value for the property in the tenant.
3.Description – enter a short description for the property.
4.Value Type - Values are stored in the database using one of 5 formats: Date, DateTime, Number, Integer (whole number), or Text. If the property will be a list selection, choose that list from the drop down menu. These lists are created at the Tenant level within the lists page. If the property will contain free form text, just select Text.
5.Property Type – There are four types of interaction properties: Case, Question, Answer, and Find Answer. The Find Answer property type is only used within Find Answers knowledge base articles. The diagram below shows how Case, Question, and Answer properties are related to a conversation. There will always be only one value saved in the database for case properties, but question and answer properties can have values associated with each individual question or answer.
6.Group name – if this property is included with others into a group, enter the group name here.
7.Required - When a property is marked as required, a user must enter a value when submitting a form that contains the property. For question properties, the value must be entered when the interaction is created. For answer properties, the value must be entered when the interaction is resolved. See Required Properties for more details.
8.Shared Property – If you want all users of iService to view these contact properties, regardless of their access to this segment, then select the Share Property checkbox. Otherwise, leave this box unchecked and only agents that have explicit access to this segment will see these values within the contact and organization details.
It is important to note that you can attach interaction properties from one segment to an interaction that is queued in another segment. This can be on purpose (e.g., Feedback values are usually stored in a restricted segment, but the feedback interaction is recorded in the segment used by agents), or it could occur when an interaction is forwarded from one segment to another.
9.Multi-Line Values – A multi-line property generates a text box in which multiple lines of text may be entered. Users can enter up to 450 characters of text.
10.Allow Multiple Values – This attribute will place a [+] next to the property allowing agents to enter multiple values. For instance, a property of type phone number might allow several different numbers to be entered.
▪Has Descriptions – If the value allows multiple values, it might be desirable to provide a description for each value. For instance, an additional detail for types of phone numbers might be created with values of Home, Office, and Mobile. This additional detail would be selected in item 7 – Value Description Type. The list of Additional Details is enabled in item 7 when the Has Description box is checked.
▪Value Description Type – This is a list of additional details created in Admin Tools > Additional Details. The list will be used as the description for the Multiple Value property.
11.Customer Viewable – If the property is customer viewable, it will be displayed to the contact in their My Account page when viewing history.
▪Customer Editable – If the property is customer editable, it can be edited by the contact in their My Account page when viewing history. In order to automatically display a property to a customer on an Ask a Question form, both the Customer Viewable and Customer Editable fields must be selected.
Perhaps you want to categorize the types of conversations you have with customers using a property with a drop down list of values like Training Needed, Defect, Enhancement Request. This type of property would be related to the entire conversation, and not an individual question or agent answer within the case. In this example the Case Property would be most appropriate because it describes the entire "case", or message thread.
If you want to document something about each question the user submits, like their level of satisfaction, you would use a question property. Question properties can have a different value for every question within the case (message thread).
After you create the interaction property you have the option to associate it with a set of topics as shown in the Topic section of this user guide. When a user selects that topic in the Ask a Question form of a customer portal, the properties associated will be automatically displayed if they are set as both customer viewable AND customer editable. Unless the property is set as customer editable, it will not be shown in the Ask a Question page. However, the property will be shown to an agent in the Create Ticket page because agent's have access to those properties regardless of the customer view and edit settings. NOTE: While the association of the property with a topic determines when the question property will appear in the standard iService GUI, you can create custom forms that include any interaction property regardless of the topic configuration.
When the question is presented to an agent in the Msg Queue page, the value entered on the original question will be displayed in the Message Properties panel. The agent can change this value, which is associated with the incoming question and NOT their answer. Every additional question within the thread (subsequent reply from customer, new ticket added to the thread) will also show this original question property. In our example, the thread is discussing an issue that is related to a specific browser, so it is presented to the agent with every interaction in that thread. Changing the value of the question property will result in all future questions that are part of the thread showing the new value. For example, if the customer selected "unknown" for browser and the agent changed it to IE all future responses from the customer would display "IE" to the agent.
Perhaps you want the agent to designate their response as billable and document the minutes spend working on a solution. This would require an Answer Property, and every response from the agent could have a different value. Their first response could be marked as billable and 10 minutes of time. If the customer replied saying thanks, they could resolve that question and mark their resolution as Not Billable and 0 minutes of time. The answer values are separate for each answer created (agent response, private or public note, agent email, etc), and updating their values has no impact on other answer or question properties.
Interaction properties can be marked a "Required" to ensure that information is consistently captured. Marking a property as required has a different impact depending on the type of property: Question or Answer.
Question Property Rules
When a required property is set on a question, the following rules are enforced.
1. Customer emails are exempt from the required rule since it is can't be enforced consistently without filters.
2. Customer and Agent Ticket form submissions return a standard error when the property is not included. For manually prepared forms, be sure to include all required forms for the user to populate.
3. Properties that are not customer editable are exempt from the required check when a customer submits an Ask a Question form.
4. Questions created without a required question property (e.g., customer emails or forms submitted where the property was not customer viewable) can't be updated by an agent until a value is set. The agent will be required to set the property before they can Save as Draft or Forward the interaction to another agent.
Answer Property Rules
When a required property is set on an answer, it must have a value entered before the interaction is resolved.
Displaying required interaction properties
Required interaction properties are displayed in a bold, red color to alert the agent that a value must be entered.
© 2008 - 2021 One-to-One Service.com, Inc. All rights reserved.