DuVoice Support - vs7:manual:ivr

Dealer Locator

Anonymous (anonymous@undisclosed.example.com) — 2023-01-07T17:45:12+00:00

2026/10/02 11:51	current
Line 1:	Line 1:
	+	====== Dealer Locator =====
	+
	+	The Dealer Locator IVR application allows callers to access pre-recorded information (such as the address and phone number) for dealers located near them by entering their 5-digit ZIP code.
	+
	+	The system uses a database of ZIP codes paired with geographical data (latitudes and longitudes) to calculate which ZIP codes are within a given radius (in miles) of the caller's ZIP code. It then looks through that list to see if any of them have an associated recording; the first one it finds it will play for the caller. It will then ask if the caller wishes to continue searching for other dealers, to try entering a different ZIP code or to disconnect.
	+
	+	A touch-tone interface is provided for managing the dealer information recordings; it also provides a method for re-recording the relevant system prompts if desired.
	+
	+	===== Call Processing =====
	+
	+	The flowchart below provides a brief overview of how a typical call is processed by the IVR. This flowchart assumes that the //AllowExpand// setting is set to 1 (see the configuration section for more details). If it is set to 0, then if there are no (more) dealers found near the caller's ZIP code, the system will state that fact and then return to the auto-attendant rather than providing the No Dealers Found menu.
	+
	+	{{:images:vs7:manual:ivr-dealer-callproc.png?nolink\|}}
	+
	+	\\

IVR

Anonymous (anonymous@undisclosed.example.com) — 2023-01-07T17:45:12+00:00

2026/10/02 11:51	current
Line 1:	Line 1:
	+	{{indexmenu_n>60}}
	+	====== IVR ======
	+
	+	The 7.00 offers a number of optional add-on interactive voice response (IVR) applications. These features are designed to meet specific application needs and are not part of the default installation of the product.
	+
	+	<WRAP round info 75%>
	+	These IVR applications are not included in a standard installation and must be purchased from the manufacturer as separate add-on modules. Contact your authorized DuVoice reseller for more information.
	+	</WRAP>
	+
	+	This section describes the following optional applications:
	+
	+	\|< 85% 15% >\|
	+	^Application^Description^
	+	\|[[vs7:manual:ivr:dealer\|Dealer Locator]]\|Plays back custom-recorded information for all dealers located within a defined radius of a caller-supplied zip code.\|
	+	\|[[vs7:manual:ivr:isi\|Inventory Status Interface]]\|Manages an inventory of items, such as the contents of the minibars in a hotel's guest rooms.\|
	+	\|[[vs7:manual:ivr:martec\|Martec System Interface]]\|Delivers emergency alerts to guest room extensions based on information provided by a Martec safety management system.\|
	+	\|[[vs7:manual:ivr:prs\|Patient Reminder System]]\|Delivers appointment reminders, or simple recorded messages, to a predefined list of customer phone numbers.\|
	+	\|[[vs7:manual:ivr:rsi\|Room Status Interface]]\|Update guest room housekeeping status without having to log in to the guest's mailbox. If passing updates to the PMS is desired, the PMS must support the RSI's HTTP interface.\|
	+	\|[[vs7:manual:ivr:test\|Test Results]]\|Reports test results to patients who call in and enter a required ID.\|
	+

Inventory Status Interface

Anonymous (anonymous@undisclosed.example.com) — 2023-01-07T17:45:12+00:00

2026/10/02 11:51	current
Line 1:	Line 1:
	+	{{tag>inventory}}
	+	====== Inventory Status Interface =====
	+
	+	The Inventory Status Interface (ISI) is a telephony interface designed to allow users to report item and quantity information to one or more remote servers. Although the original conception was to provide a method for a hotel's housekeeping staff to report usage of items from the guest room mini-bar, the interface has been designed to allow for any type of inventory reporting a user may require.
	+
	+	===== Features =====
	+	* PMS integration is not required.
	+	* Mailbox creation and voice mail integration is not required.
	+	* Auto-attendant support is not required (except for providing the telephony interface).
	+	* Unlimited number of user accounts.
	+	* Unlimited number of items.
	+	* Telephony interface supports user language preference.
	+	* Administration interface allows recording item descriptions in any supported language.
	+	* Web interface supports reporting of all item and user changes.
	+	* System supports posting changes simultaneously to as many as five remote servers.
	+
	+	===== Requirements =====
	+
	+	ISI is a licensed IVR feature and must be purchased from the manufacturer on a per-site basis.
	+
	+	===== Configuration =====
	+
	+	==== Configure the server ====
	+
	+	To configure the ISI server, refer to [[vs7:manual:syscon:conn:isi\|Features \| Connectors \| Inventory Status Interface]] in the System Configuration section.
	+
	+	==== Configure the user interface ====
	+
	+	The ISI IVR can be assigned to any key within a single digit action (SDA) menu template by entering the text ''ISI'' in the //Action// field, as shown in the figure below.
	+
	+	<callout type="info">
	+	To combine the ISI and RSI user interfaces in a single call, enter the action ''ISIRSI'' instead.
	+	</callout>
	+
	+	In this example, ISI has been assigned to menu key 1, and the //SD// checkbox has also been checked to signify that the 1 key is a single-digit key (meaning it will act immediately when the caller presses 1 instead of waiting for more digits). For more on editing SDA templates, refer to the [[vs7:manual:admin:templates:sda\|Mailbox Administration section]] of this manual.
	+
	+	{{:images:vs7:manual:mbox-sda-isi.png?nolink\|}}
	+
	+	==== Record item descriptions ====
	+
	+	The Inventory Status Interface (ISI) provides an administrator telephony interface for recording item descriptions that is integrated with the standard administrator telephony interface for the voicemail / auto-attendant system. The flowchart below provides a basic overview of how to access and use this interface to record item names or descriptions.
	+
	+	These item description recordings are used within the telephony user interface as confirmation to the user that he or she entered the correct item code. If there is no recording for an item, the system will simply restate the item ID that the user entered. While that is useful for confirming that you entered what you thought you did, playing a recorded name or description further confirms that the ID entered actually is the ID for the intended item.
	+
	+	{{:images:vs7:manual:isi-admin-tui.png?nolink\|}}
	+
	+	===== User Interface =====
	+
	+	The flowchart below provides an overview of how to use the telephony interface for posting items and quantities to ISI, which the ISI server will then pass on to any registered remote servers.
	+
	+	<callout type="info">
	+	The system will verify the user ID, the password (if the user account has one) and the room number; it will only proceed from one step to the next if the data entered for the given step has been successfully validated against the ISI database. After validating the user ID, it will switch to the user's preferred language (as configured by the administrator) before prompting for the password. Item codes are also validated against the ISI database as the user enters them.
	+	</callout>
	+
	+	<callout type="info">
	+	Depending on configuration, the system may not prompt for the user ID or the password at all. If both options have been disabled, then it will skip to the request for the room number. Likewise, if it is also configured to get the room number from the caller ID or the called number and is able to do so, it will use that room number and skip directly to the prompt for an item number.
	+	</callout>
	+
	+	{{:images:vs7:manual:isi-callproc.png?nolink\|}}

Martec System Interface

Anonymous (anonymous@undisclosed.example.com) — 2023-01-07T17:45:12+00:00

2026/10/02 11:51	current
Line 1:	Line 1:
	+	====== Martec System Interface =====
	+
	+	The Martec System Interface (MSI) is an add-on feature that can receive serial communications from a safety management system, telling the 7.00 to call specified extensions and play an emergency alert message.
	+
	+	This feature does not come standard on the 7.00, but can be purchased separately. //By default, the base software is installed on the system, but must be licensed before it can be configured or used.//
	+
	+	Currently, the MSI only communicates with a safety management system (SMS) provided by Martec. If you are interested in learning more about the MSI feature and whether it can be configured to serve your particular application, please contact DuVoice Sales for more information.

Patient Reminder System

Anonymous (anonymous@undisclosed.example.com) — 2023-01-07T17:45:12+00:00

2026/10/02 11:51	current
Line 1:	Line 1:
	+	====== Patient Reminder System =====
	+
	+	The Patient Reminder System (PRS) IVR is designed to dial customer phone numbers and play some information for them (such as an appointment reminder) based on records stored in a comma-separated value (CSV) data file.
	+
	+	Custom prompting provides flexibility to use the PRS for a variety of applications. As such, its usefulness is not limited to the medical services sector, despite the use of the word patient in the title.
	+
	+	One of the features of the PRS is its ability to handle multiple data sources, each of which may be considered a separate application. The ability to have multiple applications running concurrently—each with its own data file, configuration file and results log—provides the flexibility to support, for example, reminding patients about pending appointments for multiple doctors in the same office. In addition, there are two types of PRS application that can be used:
	+
	+	* Appointment notification plays a custom greeting, states the called party's appointment date and time, and then offers the person an opportunity to reschedule if needed (this may involve either recording a message or being transferred to an extension, depending on configuration). The decision of when to call the person is based on the appointment date.
	+	* Message delivery plays a custom recording and then disconnects. As there is no associated date and time involved, the 7.00 will make the call immediately upon reading the valid record from the data file.
	+
	+	===== Caveats =====
	+
	+	Although the system's method of cycling through the applications guarantees relatively equal access to the voice lines for all configured PRS applications, there are still constraints on the system that can affect performance. Due to the use of CSV text files for the customer data, the length of time required to find a valid customer record to call will increase over time, and the larger the data file—that is, the larger the number of customers in the data file—the worse the performance will become over time. Splitting the data files over multiple applications will not alleviate this problem and may in fact exacerbate it.
	+
	+	Consequently, the PRS is really only recommended for situations where the data file size will not encompass much more than a few hundred customers.
	+
	+	===== Theory of Operation =====
	+
	+	The PRS requires at least one dedicated voice port, up to as many as all but one of the voice ports available in the system (at least one port must be available for handling incoming voice calls, at least for administrative purposes). All PRS applications configured on the system will use all voice ports for making calls. The PRS manages multiple applications by cycling between applications every time it makes a call-out to a customer. This is achieved by assigning each application an internal, consecutive ID number.
	+
	+	The flowchart below provides a basic overview of how this process works on each voice port that has been assigned the Patient Reminder application. By cycling through the applications in this fashion, each application is guaranteed equal access to the voice lines to make calls in a timely fashion.
	+
	+	{{:images:vs7:manual:prs-operation.png?nolink\|}}
	+
	+	Select one of the application types above to see what the Run application process involves, as it will vary depending on the application type.

Room Status Interface

Anonymous (anonymous@undisclosed.example.com) — 2023-01-07T17:45:12+00:00

2026/10/02 11:51	current
Line 1:	Line 1:
	+	{{tag>room_status}}
	+	====== Room Status Interface =====
	+
	+	The Room Status Interface (RSI) is a telephony interface designed to allow housekeeping personnel to report room status to one or more remote servers.
	+
	+	<callout type="primary">
	+	The RSI service is entirely separate from the hospitality service; changes to room status using RSI __will not__ be passed to the PMS via the hospitality server.
	+	</callout>
	+
	+	===== Features =====
	+
	+	* PMS integration is not required.
	+	* Mailbox creation and voice mail integration is not required.
	+	* Auto-attendant support is not required (except for providing the telephony interface).
	+	* Unlimited number of user accounts.
	+	* Unlimited number of room status values.
	+	* Telephony interface supports user language preference.
	+	* Web interface supports reporting of all status and user changes.
	+	* System supports posting changes simultaneously to as many as five remote servers.
	+
	+	===== Requirements =====
	+
	+	RSI is a licensed IVR feature and must be purchased from the manufacturer on a per-site basis.
	+
	+	===== Configuration =====
	+
	+	==== Configure the server ====
	+
	+	To configure the RSI server, refer to [[vs7:manual:syscon:conn:rsi\|Features \| Connectors \| Room Status Interface]] in the System Configuration section.
	+
	+	==== Configure the user interface ====
	+
	+	The RSI IVR can be assigned to any key within a single digit action (SDA) menu template by entering the text ''RSI'' in the //Action// field, as shown in the figure below.
	+
	+	<callout type="info">
	+	To combine the ISI and RSI user interfaces in a single call, enter the action ''ISIRSI'' instead.
	+	</callout>
	+
	+	In this example, RSI has been assigned to menu key 2, and the //SD// checkbox has also been checked to signify that the 2 key is a single-digit key (meaning it will act immediately when the caller presses 2 instead of waiting for more digits). For more on editing SDA templates, refer to the [[vs7:manual:admin:templates:sda\|Mailbox Administration section]] of this manual.
	+
	+	{{:images:vs7:manual:mbox-sda-isi.png?nolink\|}}
	+
	+	==== Record item descriptions ====
	+
	+	The Room Status Interface (RSI) provides an administrator telephony interface for recording status descriptions that is integrated with the standard administrator telephony interface for the voicemail / auto-attendant system. The flowchart below provides a basic overview of how to access and use this interface to record status descriptions.
	+
	+	These status description recordings are used within the telephony user interface as confirmation to the user that he or she entered the correct status code. If there is no recording for a code, the system will simply restate the status code that the user entered. While that is useful for confirming that you entered what you thought you did, playing a recorded name or description further confirms that the code entered actually is the code for the intended item.
	+
	+	{{:images:vs7:manual:rsi-admin-tui.png?nolink\|}}
	+
	+	===== User Interface =====
	+
	+	The flowchart below provides an overview of how to use the telephony interface for posting items and quantities to RSI, which the RSI server will then pass on to any registered remote servers.
	+
	+	<callout type="info">
	+	The system will verify the user ID, the password (if the user account has one) and the room number; it will only proceed from one step to the next if the data entered for the given step has been successfully validated against the RSI database. After validating the user ID, it will switch to the user's preferred language (as configured by the administrator) before prompting for the password. The status code is also validated against the RSI database as the user enters them.
	+	</callout>
	+
	+	<callout type="info">
	+	Depending on configuration, the system may not prompt for the user ID or the password at all. If both options have been disabled, then it will skip to the request for the room number. Likewise, if it is configured to get the room number from the caller ID or the called number and is able to do so, it will use that room number and skip directly to prompting for the status code.
	+	</callout>
	+
	+	{{:images:vs7:manual:rsi-callproc.png?nolink\|}}

Test Results

Anonymous (anonymous@undisclosed.example.com) — 2023-01-07T17:45:12+00:00

2026/10/02 11:51	current
Line 1:	Line 1:
	+	====== Test Results =====
	+
	+	The Test Results IVR was designed as a simple integrated voice response (IVR) application that allows a customer to call in, enter an ID number and receive a message based on a database entry that maps the customer ID to a particular message ID. As the name implies, it was written as a means of informing the caller of a test result, but it can certainly be used for other similar purposes.
	+
	+	===== Configuration =====
	+
	+	Configuration settings for the Test Results IVR are kept in a single configuration file named ''testresults.ini'', which is stored in the ''C:\VS\IVR\TestResults'' folder.
	+
	+	==== [General] ====
	+
	+	This section contains all settings that control the overall operation of the IVR application. They include:
	+
	+	\|< 85% 15% >\|
	+	^Setting^Description^
	+	\|//DataFile//\|Full path and filename of the comma-separated value (CSV) data file containing the test results.\|
	+	\|//LogFile//\|Full path and filename of the ASCII text file in which the application will log call activity.\\ \\ Each line in the log will contain: the date and time of the call, the voice line number on which the call was received, the user ID of the caller (if relevant), and some descriptive text.\|
	+	\|//MaxIDLength//\|Enter the maximum number of digits in an ID number. The default value is ''9'' digits.\|
	+	\|//MaxErrors//\|Enter the maximum number of times a caller can enter an invalid ID number before the IVR quits and returns the caller to the auto attendant. The default value is ''3'' errors.\|
	+	\|//MessageBox//\|Enter the mailbox in which the callers may leave a message if they have questions about their test result.\|
	+	\|//NumResults//\|Enter the number of valid test results. The default value is ''4'' results.\|
	+
	+	==== [Resultx] ====
	+
	+	For each valid test result, there must be a corresponding ''[Resultx]'' section, where //x// is a number from 1 to //NumResults//. For example, if //NumResults// is set to 4, then there must be sections for [Result1], [Result2], [Result3] and [Result4]. Each such section contains the following settings:
	+
	+	\|< 85% 15% >\|
	+	^Setting^Description^
	+	\|//Description//\|Enter a description of the purpose or meaning for this result. Optional.\|
	+	\|//Mailbox//\|Enter the mailbox that contains the prompt (greeting) that will be played to inform the caller of the test result.\\ \\ The path and filename of the actual prompt recording must be assigned to the same greeting number as that assigned to the RNA greeting for the mailbox. See Mailbox Administration for details.\|
	+
	+	===== Data Format =====
	+
	+	The Test Results IVR looks for its data in the file specified by the //DataFile// setting in the ''[General]'' section of ''testresults.ini'' configuration file, as described above. This data file uses an ASCII-text, comma-separated value (CSV) format. Each line of the file represents the data record for a single customer's test result. The following in an example record:
	+
	+	<code>132950969,1</code>
	+
	+	In this example, the customer's ID number is 132950969 and the test result value is 1. Note that the two fields are separated by a comma and that there are no extra spaces.
	+
	+	\|< 85% 15% >\|
	+	^Field^Position^Description^
	+	\|//ID Number//\|1st\|The customer's ID number.\\ \\ May contain up to //MaxIDLength// digits, as described in the Configuration section above.\|
	+	\|//Test Result//\|2nd\|The customer's test result. Valid range is from 1 to //NumResults//.\\ \\ //This number is used to look up the mailbox number from the associated [Resultx] section of the configuration file, which is then used to find the correct greeting to play to the caller.//\|
	+
	+	<WRAP round important 75%>
	+	Updating the data file while any callers are accessing the IVR is not advised and may cause the system to crash. The system reads this file every time a caller enters an ID number to get a test result. Overwriting the file while the IVR is accessing it could cause the IVR to crash.
	+	</WRAP>