Support Ticket CSV
Overview
If you don’t want to connect directly to a support datasource like Zendesk, Intercom, Helpshift, Kustomer, or a similar software, you can export the data into a CSV and upload it into Artifact. This document provides guidance on how the CSV should be formatted: both the required fields and the optional metadata fields. It also goes over the optional, supplemental CSV you can upload for person metadata. Following this guide will help you have an easy and seamless upload process.
Sample Support CSV
Each of these fields will be covered in more depth further down in this guide, but here is an example of what a support CSV looks like. This example includes the required fields (interaction_id through interaction_title columns). The remaining columns (tags and channel) are optional fields we added for filtering within Artifact.
Support CSV column guidelines
Required columns
The support CSV you upload to Artifact must contain the following columns of data for Artifact to synthesize the data and link customers together across interactions.
interaction_id: This is an id that is inclusive of all of the back and forth between a customer and the company. This might be the called the ticket_id, conversation_id, or could be something else. The column is required and the value can’t be null, an empty string, or contain any spaces. If your data doesn’t have a unique ID for every complete interaction, you’ll need to create one.
verbatim_id: This is an id for each response within the interaction – one email or chat message. This column is required and the values must be unique. Values can’t be null, an empty string, or contain a space. The pairing of the interaction_id and the verbatim_id should be unique.
text: This is the text from the ticket – what the customer or the agent said. The column is required and the field can’t be null or an empty string.
created_at: This is the timestamp of the ticket. The column is required and the field can’t be null. The format should follow the ISO 8601 standard, as follows: 1990-01-15T00:34:60.026490+09:30.
updated_at: This is the last time the ticket was updated. If it hasn’t been updated, then this would be the same as the created_at date. The column is required and the field can’t be null. The format should follow the ISO 8601 standard, as follows: 1990-01-15T00:34:60.026490+09:30.
person_id: This is the ID of the person who said the text (customer or agent). The column is required and the field can’t be null or an empty string. If your data does not include a person_id, you’ll need to create a unique ID for each person.
person_full_name: This is the person’s name or username if you don’t know their full name. The column is required, but the fields can be left empty. If left empty, when looking at verbatims in Artifact, it will be attributed to “unknown.”
person_email: This is the person’s email address (customer or agent). The column is required, but can be left empty. If possible, please provide as it helps Artifact identify a user across all datasources.
affiliation: This describes if the text was from a customer (EXTERNAL), from someone within the company (INTERNAL), or from an automation bot (AUTOMATION). The column is required and the field needs to contain either EXTERNAL, INTERNAL, or AUTOMATION. The value can’t be null or an empty string.
interaction_title: This is the ticket title, if provided. This column must be present, but can be null or an empty string.
Optional support metadata columns
If there is additional information about the support tickets (but not the customer) that you want to filter by in Artifact, you can add columns with this information. For example, if I wanted to filter by tags, satisfaction rating, priority, channel or another value, I would add columns like these to the CSV:
tag | satisfaction_rating | priority | channel |
wrong order | 5 | high |
When going through the CSV upload process, these columns will be left as unmapped.
Optional person metadata CSV
If there is additional information about the customer that you want to filter by in Artifact, this should NOT be added to the support CSV. Instead, once the support CSV has been uploaded, there will be a prompt to add a person metadata CSV. Think of this like a separate customer table in the same datasource.
Person metadata CSV required fields
person_id: This should be the same person_id that is used in the support CSV. The column is required and the value can’t be null, an empty string, or contain any spaces.
person_email: This is the email of the person. The column is required, but the value can be null or an empty string. Please note that this helps us conduct identify resolution across the different data sources so if possible, please provide it.
created_at: This is when the person was first seen or created within the support data. The column is required and the field can’t be null. The format should follow the ISO 8601 standard, as follows: 1990-01-15T00:34:60.026490+09:30.
updated_at: This is the timestamp for the last time the person was updated. The column is required and the field can’t be null. The format should follow the ISO 8601 standard, as follows: 1990-01-15T00:34:60.026490+09:30. If no updates have happened, then the value would be the same as the created_at field.
Optional metadata fields
After the required columns, any metadata that you want to filter on can be added. Some examples of person metadata that you would want to filter on include customer_state, customer_country, role, segment, or last_seen.
Important considerations for the Support CSV
The number of interactions in the CSV will be subtracted from your monthly amount.
Person data doesn’t affect your monthly interactions.
Don’t upload interaction data older than your look back period.