Advanced Contact Center Solutions Expanded IP Office Telecommuter Mode for use by remote Avaya Contact Center Select (ACCS) Agents December 2015 Ver: 1.0 Abstract This application note describes how Avaya customers can now utilize the IP Office Telecommuter feature to deploy Avaya Contact Center Select agents in classic and expanded Telecommuter mode. Current releases of ACCS and IP Office support a classic deployment of the telecommuter feature with POTS (Plain old Telephone System) telephones for use by ACCS agents. In order to address specific geographical sales opportunities, Avaya are introducing support for a new expanded IP Office telecommuter deployment with remote ACCS agents. The new expanded mode refers to ACCS agents using IP Office Telecommuter mode with fully featured PBX telephones. Supported PBXs are Avaya IP Office with Avaya telephones or 3rd party PBX systems and associated telephones connected to the platforms via productized trunks (ISDN & SIP). Critical limitations of this new expanded mode will clearly be presented and documented. There are no plans to address any documented limitations in future application platform releases either on IP Office or ACCS. /EoH 1 of 21
Table of Contents 1. Introduction... 3 1.1. Documentation Sources... 4 1.2. Supported Releases... 4 1.3. IP Office Telecommuter Mode Explained... 5 1.4. IP Office Classic Telecommuter Mode for ACCS Remote Agents... 7 2. IP Office Expanded Telecommuter Mode for Remote ACCS Agents... 11 2.1. IP Office Telecommuter Mode for ACCS Remote Agents... 17 2.2. Summary and Overview... 21 /EoH 2 of 21
1. Introduction IP Office Telecommuter feature is a long established capability which allows a user to deliver all calls intended for the user to another telephone as long as it is reachable from their home PBX system. In very simple terms, the classic use case allows a telecommuter enabled home worker (can also be a contact center agent also) to receive their calls at their home based PSTN (POTS) telephone device. The typical scenario is the remote worker that occasionally works from home or from any remote location or road warriors. The POTS phone will ring, they answer the call and the audio path for the call is delivered to that phone even though that phone is not their configured home IP Office Extension. Full details of the Telecommuter feature with explanations for the different terms will be presented in later sections of this document. IP Office Telecommuter feature can and is used by contact center customers to deploy a remote agent usually at their home location, without having to deploy a specialized telephony device (i.e. VPN telephone) at their physical location. The purpose of this application note is to provide information regarding the expansion of this typical home agent with POTS device to a remote user with a fully featured PBX telephone as their telephony device. This user s fully featured phone can be homed off an Avaya IP Office PBX or a 3rd party PBX. This expanded mode comes with a number of documented limitations (see limitations chapter) which will not be addressed by future IP Office or ACCS application development. These limitations are common to all telecommuter deployments from all UC vendors PBX systems. /EoH 3 of 21
1.1. Documentation Sources This application note does not provide step by step instructions to the reader on how to configure IP Office telecommuter mode for remote users. It also does not provide instructions for enabling remote worker (often referred to as Off-site Agents) in the ACCS application. Readers are advised to consult the currently published customer documents particular the following available either on http://support.avaya.com or IP Office publishing portals such as IP Office knowledge base. Avaya Contact Center Select Agent Desktop Guide Release 6.4, Issue 01.02 December 2014 or newer versions for ACCS 7.x when published in December 2015. 1.2. Supported Releases This application note provides an additional deployment option for remote ACCS agents using the IP Office telecommuter mode. The following table shows the different product release support for both classic and expanded telecommuter mode. Telecommuter Mode ACCS Version Classic 6.4.x, 7.x Expanded 6.4.2, 7.x The next two sections describe what is meant by the terms classic and expanded /EoH 4 of 21
1.3. IP Office Telecommuter Mode Explained What is IP Office Telecommuter mode? Let s start with a definition: IP Office Telecommuter Mode Definition: IP Office Telecommuter mode allows you to make and receive calls using a phone at a remote location with all calls being started by and going via your home telephone system i.e. in Avaya s case this will be an IP Office UC platform. The following terms will be used throughout this document to refer to different aspects/components/features of the IP Office Telecommuter Mode. Note that in some of the ACCS agent screens and ACCS documentation, the term Teleworker is utilized. (1) Telecommuter User = any user who has the telecommuter feature configured on their internal extension on the home/main office IP Office platform. (2) Telecommuter User Internal Extension: This is the telecommuter user HQ/main site IP Office internal extension which has the telecommuter feature enabled. If this user was based at the main site, then this extension would be their extension for everyday use. While telecommute mode is selected, you are logged out of your normal internal phone extension. (3) Telecommute Phone: The endpoint (with associated number) where the telecommuter user s calls are actually delivered to. Once a user is working in telecommuter mode all incoming calls to your internal extension are redirected to thee telecommute phone number. The telecommute phone device is assumed to be at the users location. (4) Telecommuter User Browser: Browser access (requires data connection) back to main site to allow the telecommuter user configure their telecommute phone number. Telecommuter users use the browser to connect back to their main IP Office (company's one-x Portal for IP Office server) in order to configure themselves in/out of telecommuter mode. While telecommute mode is selected, you are logged out of your internal phone extension. Please consult IP Office documentation for supported browsers. (5) Telecommuter Nailed Up Voice Path: An actual voice media path established from the telecommuter user s internal extension to the telecommute phone device (number) The HQ/main site phone system will make a call (the nailed up voice path) to your configured telecommute number and when answered all calls for the user inbound or outbound are delivered over the nailed up voice path to/from the telecommute number by the HQ/main site phone system. IP Office supports two nailed up modes (a) On Demand where the telecommuter number is called every time for incoming/outgoing calls or (b) Permanent nailed up mode where the telecommuter number is called ONCE. ACCS only supports the permanent nail up mode. /EoH 5 of 21
The following diagram shows the above elements of the IP Office Telecommuter deployment for a generic UC user. This diagram shows the reference architecture for any IP Office UC user enabled for Telecommuter mode. The next section describes how Avaya Contact Center customers have taken this architecture and used it to deploy remote ACCS agents using telecommuter mode. /EoH 6 of 21
1.4. IP Office Classic Telecommuter Mode for ACCS Remote Agents Remote contact center agents are all agents that do not physically reside in the contact center itself. Modern communications systems allow remote users to be physically located away from the actual location hosting the contact center. Customers can deploy remote telephones or remote gateways which allow them to deploy remote agents at those locations. However it is not practical to deploy enterprise infrastructure say at an agent s personal home and this is the classic use case for telecommuter mode working. Using the previous sections information, we can now discuss how contact centers utilize the telecommuter capability to deploy these remote agents say working from the own personal home. All of the terms in the previous section remain unchanged except for the term number (4) Telecommuter User Browser. In order to be able to work as an contact center agent, the user must have some mechanism to be able to login to the contact center to become ready to take contact center routed calls. They also must be able to signal to the contact center when they wish to be Not Ready or take a break or simply logout. The standard mechanism to achieve contact center agent capability at a remote location is to deploy a contact center desktop (if one exists and they usually do) from the contact center platform onto the user s /Workstation/Laptop provided by the enterprise. This implies also that the user must have a sound data connection back to the location hosting the contact center platform. In the modern world this is not a problem with modern data connectivity. Therefore the simple browser application that we referred to in the previous section is now replaced with a more functionally rich contact center application which not alone allows the user to configure themselves in telecommuter mode but work as an agent also. Some vendors may not be able to provide a single application for this but the Avaya agent desktop from ACCS which is known as Avaya Agent Desktop (AAD) performs both functions. We can now show the classic ACCS remote agent architecture with the IP Office telecommuter feature. Figure 1.2 Architecture for classic remote ACCS agents using IP Office Telecommuter Mode /EoH 7 of 21
The following steps outline how a remote user using the IP Office telecommuter mode can operate as an ACCS agent once they have been configured on the for telecommuter mode. 1. Remote user opens up their ACCS desktop AAD on their /Workstation 2. When prompted at login, they select other phone mode. 3. In the drop down they enter the number of the telecommute phone that they want to use when logged into the ACCS application as a telecommuter user. 4. They now complete the login to the ACCS contact center 5. Immediately the device configured with the telecommute phone will ring ( assuming the agent has entered a valid telephone number) and once the agent answers this call, they are now ready to receive new ACCS routed calls ( once they make themselves READY via the AAD application). Step 5 establishes the permanent telecommuter nailed up voice path which is supported by ACCS. 6. For telecommuter enabled ACCS agents using AAD, the IP Office telecommuter user internal extension number appears on the telecommute phone display as the calling line ID (CLID) and not callers number. The telecommute phone display will not show information (CLID, DNIS) about ACCS routed customer calls. This is standard working of all telecommuter deployment. Agents can use the information shown on AAD (CLID/skillset) to identify the caller assuming there is no screen pop of additional customer data. 7. Once the ACCS agent logs out using AAD the telecommuter nailed up voice path will be automatically disconnected. It may not be immediately clear but in reality, the ACCS agent calls are first delivered to the telecommuter user internal extension (at the Main HQ site IP Office). Because they have been configured with telecommuter mode, the media for calls are redirected out to the telecommute phone the agent has entered when the logged in on their agent desktop. The telecommuter calls never ring/alert on the internal extension nor do they ring on the telecommute phone once telecommuter nailed up voice path is fully established. The only notification that the agent receives is on their agent desktop which alerts on an incoming new call. The following steps show how an agent answers an ACCS routed call in telecommuter mode (assume they have successfully logged in and are in an Ready state and telecommuter nailed up voice path established). 1. ACCS select agent for new customer call. 2. ACCS targets the call at the telecommuter user internal extension but as this is now configured in telecommuter mode, the call (voice media) is redirected out to the telecommute phone at the agents location. 3. Agent s ACCS desktop AAD will now be alerting because it is monitoring the telecommuter user internal extension from a CTI perspective. 4. A single beep is played to the agent through the nailed up voice path. 5. Assuming the agent notices the AAD alerting, they must answer the call using AAD there is no alerting on the telecommute phone device /EoH 8 of 21
6. If they answer the call with AAD, then they now have a voice path established between the telecommute phone and the caller s (i.e. customer) device. If they do not answer the call, it will return to the ACCS skillset using RONA (Return on No Answer) as per standard ACCS feature set. This symbol indicates great caution should be taken when operating in any telecommuter mode from any vendor. Special training is required for all telecommuter mode workers to ensure they remain working in a fully supported manner. Note: ACCS agents operating in telecommuter mode must adhere to strict guidelines on call handing methods regardless of the underlying UC platform Avaya or 3rd party. There is one golden rule which all ACCS telecommuter enabled users must follow: All telephony operations performed by the ACCS agent must be carried out on their desktop application (AAD) and never on the telecommute phone supported telephony operations such as answer/release/transfer/conference/hold/unhold etc (this is not an exhaustive list of operations). Performing any of the above telephony operations on the actual telecommute phone can (and will) lead to loss of the telecommute call including the telecommuter nailed up voice. In such instances, it will be necessary for the agent to either (a) use the ACCS desktop recovery button (see later sections) and (2) re-login and re-establish the telecommuter mode of operation once more. The following rules govern ACCS agent operations who work in the IP Office telecommuter mode: (a) The home/main IP Office platform has no visibility in terms of CTI events of the telecommute phone which receives the actual telecommuter call. (b) All telephony operation performed on the telecommute phone are NOT VISIBLE to any CTI application being used by the agent. a. If the telecommuter agent places the telecommuter nailed up voice on hold using the telecommuter phone, the ACCS agent s desktop AAD will still see the call as being active. ACCS telecommuter agents must always remember to use the AAD desktop application to perform all operations on a telecommuter call never use buttons/controls on the telecommute phone to perform any operation release/transfer/conference/hold other than the initial answer of the telecommuter nailed up voice path. /EoH 9 of 21
The classic telecommute number is associated with a single line telephone device (POTS phone) with a very limited feature set no transfer/conference etc. This mitigates against the agent accidently or maliciously dropping the ACCS call including the telecommuter nailed up voice path. Up until the publication of this application note on expanding the telecommuter mode use case, the only phone device supported for ACCS agents is a POTS based device with a single line appearance using the strict agent operating guidelines above. This is called out in the current ACCS 6.x customer documentation and will not be changed in future documentation updates. The current IP Office documentation set and knowledge base as of November 2015 also stipulate the following The phone at the telecommute number location is assumed to be a single line phone. /EoH 10 of 21
2. IP Office Expanded Telecommuter Mode for Remote ACCS Agents We are using the term Expanded to signify that the new mode being discussed in this application note on the existing classic remote ACCS agents using POTS devices in telecommute mode. The difference between classic and expanded mode is the use of a fully featured PBX telephone for the agents telecommute number. A featured PBX telephone is any telephone (connected to that PBX) with standard features like transfer, conference, hold, etc., programmed as buttons or via command codes. Normal POTS devices do not contain such capabilities normally. So to move from the classic POTS telecommuter deployment, replace the POTS device with a PBX featured phone and you now have the expanded telecommuter mode. In the previous chapter, we introduced the term Telecommute Phone = the endpoint and number where the telecommuter user s calls are delivered. This term also applies to the expanded except that the telecommute phone number is tied/configured on a fully featured PBX device. The next question to ask is what is the PBX being referred to in the term fully featured PBX device? The following diagram now shows the new expanded mode architecture. Figure 2.0 Architecture for remote ACCS agents using expanded IP Office Telecommuter Mode /EoH 11 of 21
With reference to the diagram, there is one major difference between the expanded and classic IP Office telecommuter modes. At the telecommuter agent location, there is now an additional PBX platform with fully featured telephones available to the remote users agents and non agents. These featured telephones are now the endpoint devices used by remote agents. These phones have a dial able directory number and are part of the overall telephony dial plan between the main site and the remote site. The main site still contains the IP Office and associated ACCS application. To enable any user at the remote site to be an ACCS agent, the system administrator allows the remote agent to configure their telecommute phone number to be the same number as their featured PBX extension number. When they login to the ACCS application, they select this featured phone device as their telecommute phone number. Another subtle difference between classis and expanded is that the remote ACCS agent must now have two programmed extensions (1) One programmed extension on the main site (telecommuter user internal extension) with the Telecommuter Mode enabled ( ext. XXXX in the diagram) and (2) One programmed featured extension (telecommuter phone) on the remote PBX ( ext. YYYY in the diagram). The remote extension YYYY is the extension normally used by the agent on a day to day basis. This is their published number which appears on all devices which they make calls to and is the number all other users call when they wish to communicate with this remote agent. The remote PBX itself can be an Avaya IP Office platform, an Avaya Enterprise platform ( Avaya Aura Communication Manager) or any 3rd party PBX platform with 3rd party telephone devices connected over a supported trunk interfaces SIP or ISDN. H.323 trunks are not supported. The introduction of this fully featured extension with its own dial able number greatly complicates the classic IP Office telecommuter mode of operation. In order for Avaya to support a workable solution in this expanded mode, the following strict guidelines apply to all deployments. The following steps give a high level summary of the remote ACCS agent operations when working with telecommute calls. 1. The telecommute phone is now be a fully featured extension i.e. controls on the phone for hold, transfer, conference, coverage path etc. 2. The remote ACCS agent performs a login to ACCS using AAD ( Avaya Agent Desktop) 3. During the login process they will specify that they are operating in telecommuter mode and specify the telecommute phone where the actual calls will be delivered to which in this case is ext. yyyy. 4. Once the login process succeeds, the remote agent is logged into ACCS with Telecommuter Mode enabled to telecommuter phone yyyy from the telecommuter user internal extension xxxx /EoH 12 of 21
5. In order to deliver all ACCS routed calls to the remote agent, the telecommuter nailed up voice path is first established from the main site IP Office telecommuter user internal extension out to the telecommute phone yyyy. 6. The remote agent answers this telecommuter nailed up voice path using extension yyyy answer button. This establishes the telecommuter nailed up voice path to the ACCS agent s telecommute phone where they will handle all calls internal/external and ACCS routed calls. 7. Once established the agent no longer interacts/touches telecommute phone yyyy but instead must use the ACCS agent application on their /Workstation which is AAD for all call manipulations hold, transfer, conference, etc. 8. Note: they must not make/receive non ACCS calls whilst logged in as an ACCS agent in telecommuter mode. ACCS routed calls to the remote agent shall be delivered using the following simple steps: 9. ACCS skills based routing now directs an ACCS call to the remote agent using ext. yyyy. 10. Main Site PBX (IP Office) internally alerts/rings telecommuter user internal extension XXXX but as the user (remote ACCS agent) is configured in telecommuter mode, the actual voice media is delivered out to the telecommute phone number which is yyyy. 11. On the remote ACCS agent desktop, the agents CTI application (AAD) starts to alert to prompt the agent to answer the incoming ACCS call there is no ringing or alerting on the telecommuter phone yyyy. 12. If the remote agent wishes to terminate/transfer/conference/hold the ACCS routed call, they must use the AAD application to perform this function and not the telecommuter phone yyyy. 13. No telephony operations on telecommute phone are allowed while logged into ACCS in telecommuter mode 14. The next ACCS call for this agent will be delivered to the agent in the same manner through the telecommuter nailed up voice path without having to re-establish the telecommuter nailed up voice path that is how the permanent telecommuter nailed up voice path mode operates and that is the only mode which is supported by ACCS. Remote agents cannot make/receive direct calls whilst logged in as an ACCS agent in IP Office telecommuter mode on a fully featured PBX device This is not a supported configuration by Avaya. If the remote user end up where they have two calls on their extension (1 ACCS routed call and 1 direct call), then it is almost guaranteed that the remote user can and will lose control of either of these calls. /EoH 13 of 21
Net result can and will be either (1) re-establishment of the telecommuter mode using the ACCS recovery button (see later section) without loss of the existing call or (2) re-login and re-establishment of the telecommuter nailed up voice path etc once more with loss of the existing customer call. If it is a requirement for the remote ACCS agent to be able to handle personal/direct inbound/outbound calls whilst working as a telecommuter agent, then it shall be necessary to deploy a secondary local extension (physical/soft) for the remote users for all non ACCS calls. Remote agents must always remember to use AAD to perform all operations on all calls agent initiated internal, outbound and ACCS routed calls never use buttons/controls on the telecommute phone perform any operation release/transfer/conference/hold other than the initial answer of the telecommute nailed up voice path call. In expanded mode the same limitations apply. 1. The home/main office IP Office has no visibility in terms of CTI events of the fully featured telecommute phone at the remote location which receives the actual t telecommute nailed up voice path call. 2. All telephony operation performed on the telecommute phone where the telecommute nailed up voice path are NOT VISIBLE to any CTI application being used by the agent including ACCS desktop AAD. a. If remote agent puts a telecommute call on hold using telecommute phone controls, AAD will see the call as still being active and not on hold. 3. No telephony operations on telecommute phone are allowed while logged into ACCS in telecommuter mode 4. Agents can accidently drop/release/transfer/conference/apply coverage path to a telecommute call if they use controls/buttons on the telecommute phone there are no guardrails to prevent this happening and there no plans to introduce any guardrails as part of the Avaya roadmap. 5. Agents can deliberately transfer/conference/coverage path a telecommute call. This can be viewed as a potential misuse and also a security issue where calls are diverted to non secure endpoint. There are no guardrails to prevent this happening and there no plans to introduce any guardrails as part of the Avaya roadmap. 6. Customer site issues are difficult to resolve as telecommute calls traverse across multiple PBX systems (minimum of 2) with no consolidated logging/debug tools. 7. There are no new records of agent mis-use of the telecommute call. Customers can utilize ACCS historical reporting to analyze telecommuter agent behaviors. /EoH 14 of 21
/EoH 15 of 21
The following table summarizes the DO s and DON T s for all remote ACCS agents operating with expanded IP Office telecommuter mode enabled deployments. Supported Not Supported Use ACCS Agent Desktop AAD to login/logout as an ACCS Agent Use ACCS Agent Desktop AAD to change agent state to Ready/Not Ready Use ACCS Agent Desktop AAD to make/answer/release/hold/unhold/transfer/conference/join all calls internal agent initiated inbound and outbound and all ACCS routed calls whilst logged in as an ACCS agent Use telecommute phone (physical or soft) controls to answer the INITIAL or any RECOVERED Telecommuter Calls Use ACCS Agent Desktop recovery button to recover all Customer Calls mistakenly released/transferred/conferenced/held when using the Telecommuter Actual Phone Controls see next section for details on ACCS desktop recovery button. It is not supported to use the telecommute phone controls to answer/release/hold/unhold/transfer/conference all calls - internal agent initiated inbound and outbound and all ACCS routed calls whilst logged in as an ACCS agent It is not supported to use telecommute phone number feature phone when logged in to ACCS for any non ACCS calls either inbound or outbound. No telephony operations on telecommute phone are allowed while logged into ACCS in telecommuter mode Do use the telecommute feature phone for all non ACCS calls when logged out of ACCS only The next section will now discuss a unique capability of the ACCS agent desktop called the telecommuter call recovery button which was designed to recover the telecommuter call in certain failure situations. /EoH 16 of 21
2.1. IP Office Telecommuter Mode for ACCS Remote Agents Telecommuter mode of operation is replete with pitfalls and risks for the end user operating in that mode especially when they have a fully featured PBX device as their telecommute end point. The ACCS application comes with specifically designed agent controls embedded in the desktop AAD, which can be used by the agent to mitigate against loss of the telecommuter call either accidently or deliberately. As stated in the previous sections, there are no guardrails available to prevent any of the pitfalls of telecommuter mode from occurring other than never using the feature buttons/controls on the telecommute phone and instead using the ACCS agent desktop whilst logged in as a working agent. How does the ACCS agent working in telecommuter mode fall into some of the most common traps? If they use the telecommute phone number device to perform any telephony task such as transfer or conference or hold, then they have a problem. In order to recover this problem, they can utilize the AAAD recovery button to reinitiate and answer a new telecommuter nailed up call. Once they complete this action, the existing customer call will be returned to that agent on their telecommuter number device this presumes that the customer on the call has not already disconnected. Here are other potential pitfalls with automatic recovery mechanisms from the ACCS application. If the remote ACCS agent accidently or deliberately disconnects the permanent telecommute nailed-up call while active on a customer call, home/main IP Office automatically reinitiates the telecommuter nailed up to the telecommute number endpoint. If the remote agent disconnects the nailed-up call while idle, home/main IP office automatically reinitiates the nailed-up call when the next customer call is presented to the remote agent. The following series of ACCS agent desktop show the progression from a logged out telecommuter/teleworker agent to a fully logged in ACCS agent with telecommute call established. /EoH 17 of 21
Figure 2.1 Logged out ACCS telecommuter agent Teleworker status not established Figure 2.2 Logged in ACCS telecommuter agent Teleworker status established In the above example, a successful nailed up telecommute call will result in the telephone icon displayed as green. This icon is not just for display purposes. A remote ACCS user can hover over this icon at any time to check the status of their telecommute nailed up voice call. They can also click on this icon to recover the telecommute nailed up voice call/path when required. Figure 2.3 Logged in ACCS telecommuter agent Teleworker status established with tooltip /EoH 18 of 21
Figure 2.4 Logged in ACCS telecommuter agent Teleworker status failed to Establish In the above example, if subsequent attempts to reestablish the telecommute nailed up call by clicking on the red phone icon, then the remote ACCS agent must logout of the ACCS application, lo on again and try to establish the telecommute nailed up voice path. Figure 2.5 Logged in ACCS telecommuter agent Teleworker status failed to Establish Warning Message to Agents Figure 2.6 Logged in ACCS telecommuter agent Teleworker status failed to Establish Agent uses Recovery Button to reestablish Telecommuter Nailed up Call on their desk phone In the above example, the telecommute nailed up call status stays yellow until the agent answers the call on their telecommute number phone. Once they do this, the status icon will go green. /EoH 19 of 21
The following table summarizes briefly transfer and conference actions on the agents telecommute phone device that can be recovered using the AAD telecommuter/teleworker recovery button Situation Agent Remedial Action Expected Outcome Agent active on ACCS Contact Center Call in Telecommuter Mode. Agent mistakenly transfers the existing call to an unintended destination (wrong ext. number or goes to voicemail of destination party) using Telecommute Agent phone and not AAD on their /Workstation Agent active on ACCS Contact Center Call in Telecommuter Mode. Agent mistakenly conferences the existing call to an unintended destination (wrong ext. number or goes to voicemail of destination party) using Telecommute Agent phone and not AAD on their /Workstation Agent presses the Telecommuter/Teleworker status button to attempt to retrieve the telecommute nailed up permanent call and the actual customer live call. Agent presses the Telecommuter/Teleworker status button to attempt to retrieve the telecommute nailed up permanent call and the actual customer live call. Immediately the agent is put into an NOT Ready State. After a short delay, the agent s telecommute number phone device alerts/rings. Agent answers the call on the telecommute number phone device not using AAD Original customer call is now present again and Agent is talking once more to caller Immediately the agent is put into an NOT Ready State. After a short delay, the agent s telecommute number phone device alerts/rings. Agent answers the call on the telecommute number phone device not using AAD Original customer call is now present again and Agent is talking once more to caller In both situations above, the agent is not prompted to utilize the AAD recovery button. All remote ACCS agents operating in telecommuter mode must have specific training for the role and only they will know when and when not to use the recovery button. /EoH 20 of 21
2.2. Summary and Overview All UC vendor s telecommuter mode of operation contains limitations regardless of the underlying PBX and Contact Center applications. Despite all of the limitations, there are many customer deployments in production today using the expanded telecommuter mode of operation across Avaya PBX systems (midmarket and enterprise based) and 3rd party PBX platforms. With special training, remote telecommuter/teleworker agents can utilize the technology without failure once they adhere to the recommended usage guidelines. The platforms go one step further in that they provide some automatic and manual recovery mechanisms for the telecommuter enabled user to mitigate against certain unforeseen situations. Avaya and the Avaya Logo are trademarks of Avaya Inc. All trademarks identified by and are registered trademarks or trademarks, respectively, of Avaya Inc. All other trademarks are the property of their respective owners. The information provided in these Application Notes is subject to change without notice. The configurations, technical data, and recommendations provided in these Application Notes are believed to be accurate and dependable, but are presented without express or implied warranty. Users are responsible for their application of any products specified in these Application Notes. /EoH 21 of 21