Naming Conventions

Overall Principles

• Be consistent
• Names should be as short as possible without sacrificing clarity
• Use all capital letters in names to keep casing simple and straightforward
• Use underscore _ between words or name components
• Letters and numbers, but no spaces and no any other characters except underscores
• Use common abbreviations (HOG, SVT, GE, HD), but ensure they are clearly defined in the Common Abbreviations and Acronyms page.
• Be consistent! Historically, we have not been good at this.

Flows

Components:

Main Name Component

• Named according to business purpose
• Use consistent naming for call flows from similar business areas, e.g., Help Desk BC Registries and Help Desk BCeID call flows are called HD_BCROS and HD_BCEID

Channel Component

• VOICE: voice
• SMS: Short Message Service (SMS), i.e., text messaging
• EMAIL: email
• WEBMSG: web messaging, n.b., not web chat, which is a different Genesys offering.
• VM: voicemail
• VIDEO: voice channel for video calls

Language Component

• always specify for any language, including English
• English: EN
• French: FR
• Cantonese: CA
• Mandarin: MA
• Punjabi: PJ
• Hindi: HI
• Spanish: SP

Division Component

• BAT: business acceptance testing division
  • convert any flows with UAT in name to BAT
• PROD: production division
• TRN: training division

Examples:

• GE_VOICE_EN_BAT
• VBV_VIDEO_EN_PROD
• GENERAL_WEBMSG_FR_PROD

Queues

Queues use the same rules as Flows. Note that many call flows and queues will therefore share a name, but many call flows will also contain queues of a different name. For example, the HD_BCEID_VOICE_PROD call flow contains a HD_BCEID_VOICE_PROD queue, but it also contains the queues HD_PAYBC_VOICE_PROD and HD_TRB_VOICE_PROD, as well.

Components:

Main Name Component

• Named according to business purpose
• Use consistent naming for queues from similar business areas, e.g., Help Desk BC Registries and Help Desk BCeID queues are called HD_BCROS and HD_BCEID

Channel Component

• VOICE: voice
• SMS: Short Message Service (SMS), i.e., text messaging
• EMAIL: email
• WEBMSG: web messaging, n.b., not web chat, which is a different Genesys offering.
• VM: voicemail
• VIDEO: voice channel for video calls

Division Component

• BAT: business acceptance testing division
• PROD: production division

Examples

• GOVERNMENT_AGENT_VOICE_PROD
• MACS_SMS_BAT
• HD_BCROS_NAMES_WEBMSG_PROD

Data Tables

Same as Flows and Queues?

Components:

Main Name Component

• Named according to business purpose

Channel Component

• VOICE: voice
• SMS: Short Message Service (SMS), i.e., text messaging
• EMAIL: email
• WEBMSG: web messaging, n.b., not web chat, which is a different Genesys offering.
• VM: voicemail
• VIDEO: voice channel for video calls

Division Component

• BAT: business acceptance testing division
• PROD: production division
• TRN: training division

Examples:

• GOVERNMENT_AGENT_VOICE_PROD
• HD_BCROS_NAMES_WEBMSG_PROD
• SHD_AD_HOC_VOICE_PROD
• SHD_CB_VOICE_BAT

Call Reports

The Call_Report is a variable stored in Participant Data that shows the path the interaction has taken through a call flow or call flows by appending a string to indicate the current place in the flow, sort of analogous to a call type in Cisco UCCE. We could use flow outcomes instead, but a Genesys org is limited to only 100 flow outcomes, which is nowhere near enough for us. Note that while you cannot use a Call Report variable in an interaction report (Performance tab), you can extract data and search (or filter) it in Excel.  

Components:

Queue Name Component

The name of the queue

Channel Component

Only Voice or Video calls are likely to have a Call Report, but all of the options are listed, just in case:

• VOICE: voice
• SMS: Short Message Service (SMS), i.e., text messaging
• EMAIL: email
• WEBMSG: web messaging, n.b., not web chat, which is a different Genesys offering.
• VM: voicemail
• VIDEO: voice channel for video calls

Division Component

• BAT: business acceptance testing division
• PROD: production division

Progress or Step Component

There should be a progress or step name after any decision or menu selection or prior to transferring the interaction to ACD (i.e., queueing the interaction) or transferring the call out of the system. If after a menu selection, please indicate both the menu and the caller’s selection, e.g., GE_VOICE_PROD_MAIN_SVT would indicate: Production GE voice queue, main menu, the caller selected the SVT option). Standard steps include:

• STAT - if the schedule determines the current day to be a holiday where the queue is closed
• CLOSED - if the schedule determines that the queue is closed
• CLOSED_VM - if the queue is closed and the caller has opted for the option to leave a voicemail (if applicable)
• NALO - if the schedule is active but there are no agents logged on for the queue
• QUEUE - the call has passed the time of day and agent checks and is about to be sent to ACD (i.e., queued)

Examples:

Schedules

Schedules should be named for the flow or queue they serve.

Stat schedules

For statutory holidays, they should have “STAT_” prepended to the name so that all of the holidays are grouped together. This makes it easier to assign and verify them within the schedule group. Because there was a collision on some stat names in the SBC (maximuscanada) org, stat schedules are prepended with “BC_STAT_“

Schedule Groups

Groups (for agents’ assignment to queues)

WebRTC Phones

FirstName_LastName_WEBRTC

Question: should the name component be uppercase?

Examples:

• Jordan_Marlatt_WEBRTC

Prompts

There are two types of prompts in Genesys: (pre-)recorded and text-to-speech (TTS). TTS prompts are text strings that are read aloud by a TTS provider (Amazon Polly, Azure Speech Services, Google Cloud Text-to-Speech, among others). This text is only when a caller reaches that point in a flow, in real time, and TTS services typically charge by the character. The cost of each individual message is very small, but because each flow contains many prompts and we receive thousands of calls every day, the cost adds up pretty quickly. On the other hand, using TTS allows us to use strings in data tables to allow Operations to decide the content of each message, which allows the flows to be changed dynamically, without requiring edits to the flows themselves, which reduces requests to our team. Pre-recorded prompts are recorded using a TTS service once and then the resulting audio file is uploaded to Genesys, and once it is uploaded, it can be played by Genesys as many times as needed without any additional cost. Because pre-recorded and TTS messages both have their advantages and disadvantages, we use a mix of both, with TTS messages used anywhere the message content is likely to be changed periodically and pre-recorded messages for messages that will be played many times (e.g., hold messages) or messages that are unlikely to change very often (e.g., greetings, CSAT survey invitations, etc.). Prompt names must be predictable and consistent because they may exist either as named audio files in Genesys or string names specified in data tables, or possibly both. It’s for this reason that the same convention is used for either type of prompt.

Components:

Flow or Queue Name Component

The name of the queue or, if it’s a message shared across multiple queues or flows, SHD for ‘shared’. If the audio file applies to a flow, rather than a queue, use the flow name instead:

Message Type	Flow or Queue
GREETING, a Menu Prompt	Flow Name
CLOSED, STAT, NALO, HOLD	Queue Name
CALL_RECORD, CSAT_INVITE, GOODBYE	SHD

Descriptive Component

There should be a descriptive name that succinctly describes the purpose of the prompt. Standard prompt descriptions include:

• GREETING - the initial message that tells the caller which service they have reached
• STAT - a message informing the caller that the service is currently closed for a holiday
• CLOSED - the message informing the caller that the office is closed (i.e., the time of the call falls within non-business hours) and providing the business hours when they can call back
• CLOSED_VM - a closed message that also gives the caller the option to leave a voice message
• NALO - a message that informs the caller that we are unable to take their call. This scenario arises specifically during business hours if there are no agent logged in to take calls, which is unusual for most queues, but can happen occasionally, for example, if agents are slow to make themselves available at the very beginning of a day. This is an error condition for most queues, but note that we typically do not tell the caller why we can’t take their call; we just apologize for the inconvenience and ask them to call again later.
• COLLECT_PI - a message that informs the caller that agents may ask for and collect personal information
• CALL_RECORD - a message that informs the caller that their call may be (or will be) recorded for quality assurance and training purposes
• CSAT_INVITE - a message that invites the caller to participate in a customer satisfaction (CSAT) survey after speaking to an agent
• HOLD - a hold message played while a caller is waiting in the queue. If a queue has multiple hold messages, append a number to the end of the name to indicate the order that the hold messages are played, e.g., VAX_HOLD_1, VAX_HOLD_2.
• GOODBYE - a farewell message played before a call is disconnected

Examples:

Divisions

Components:

Examples:

Wrap-up Codes

External Contacts: Contacts

External Contacts: Organizations

Scripts

Roles