I'm not going to give the answer to the "technical question" asked here because I believe the issue may be better handled elsewhere. What isn't entirely clear from the thread is what the POM user (Steve, I believe) is doing that creates this problem. Let me offer the following potential analysis. If this gets back to "Steve" and doesn't solve his problem, perhaps he can further explain his situation.

My assumption is that a contact record has been called. The called party has effectively stated, "Please put my number on the DNC." My hypothesis is that the POM strategy may be using the builtin POM capability to add a number to the DNC. If so, that may be a fundamental problem here that would be best solved by a change to the strategy. When POM is asked to add a number to the DNC, it does just that, it puts the subject phone number on one of its relevant "internal" DNC lists. All that goes onto that list is the number; no indication of which campaign or campaign record caused the action. In general, our practice is to inform POM users to generally avoid using this mechanism and the POM internal DNC lists themselves. Yes, the internal DNC lists can be handy as a final stop-gap to ensure that numbers on your "real" DNC list won't be called but the best practice is always to maintain your company's DNC list(s) external to POM. Just as this question is indicating, you will want to keep more information and more context for when and why a given phone number shouldn't be called. There are cases where a phone number is on the DNC for one person, but another person who uses the same number has granted permission. These are legally tricky, but you can see why globally blocking a number (and a "number" will be blocked for both voice and SMS) may not achieve the desired result.

Our recommendation is always maintain your DNC external to POM. When you feed records into POM, scrub them FIRST against your DNC and DO NOT send POM records that you don't want called. There are ways to use POM's internal DNC lists to ensure that records with a DNC number don't get imported, but again you are just loading and using the internal DNC lists as an additional fail safe, not as your primary repository for corporate DNC information.

OK, if we don't recommend using the POM "add to DNC" feature to put a number on a DNC list, what do we recommend? Use the DNC Completion Code (either the system built in or a custom completion code) to indicate when a record's phone number should go on your corporate DNC. There are multiple ways to get records marked DNC: export the contact list at the end of the job or get the info in real time via a Kafka feed or using a custom results processor. This procedure ensures that you HAVE the whole contact record which will naturally contain the USER_CONTACT_ID and all of the other attribute values from that record including the phone number, etc.

Implementing a change to the campaign strategy and/or adding a mechanism to capture and deal with records that get a DNC completion code may be slightly more work, but (a) there is probably no answer to the original question if my hypothesis earlier is true, and (b) this method will give much better information about the contact that requested DNC, when, in what campaign context, etc. because you will have built that into your DNC list updating routine and therefore will be much better able to demonstrate and defend your efforts at TCPA compliance should that be necessary.

...glen

I'd like to help but you didn't provide enough context and some of your information is a bit confusing. What type of POM licenses do you have 400 of - automated voice, preview agent, or predictive agent? Those licenses each come with a set of Experience Portal (EP) ports that will need to be administered on your EP and allocated to your MPPs. Obviously, your SM must be configured to allow each of those EP ports to make and receive SIP calls. For example, if you have 400 automated voice POM licenses, you would have received licenses for 400 EP ports. Four hundred preview licenses would have given you 800 EP ports (one outdial and one nailup) and 400 predictive licenses would have given you 1200 EP ports (3 outdial and one nailup). Depending on what type of POM licenses and campaign you are running, those are the ports you need and should have licenses for. Obviously, the SM must be licensed/configured for that number of ports. I don't know enough about the SM to tell you whether it automatically picks up a new license allocation or whether some action (possibly restart) is needed to enable these new licenses.

Francis,

Please read and employ Mike's suggestions. I'm just going to add a little "explanation" to what may be happening. Based on your description, this is an agent-based campaign doing progressive or predictive dialing. In that case, POM will detect that the call has been answered and do various things based on your settings. Normally, you'd have AMD on (not Background AMD in most cases) to determine whether it is an Answer Human case or an Answer Machine case. The process of determining that the "voice" is from an answering device rather than a person can take a bit of time -- it isn't instantaneous nor is it 100% accurate. The longer you allow the AMD algorithm to run, the more accurate it can be but there can be other consequences. Usually there is a Nuisance timer that will deliver the call to an available agent -- typically 2 sec -- even if AMD has NOT returned a decision. This ensures that your campaign can meet regulatory compliance and have fewer abandons before an agent is connected to handle the call, but this also will deliver some calls to agents that subsequently prove to be answering devices. There is NO "cure" for this -- if the AMD takes longer than the Nuisance timer, agents WILL get those calls even if the agent then determines it was an answering device. Either you set a longer Nuisance timer to have fewer of these or you tolerate it. Setting a longer Nuisance timer may violate some regulatory compliance. Pick your poison.

The behavior you report would appear to result from calls where the AMD didn't resolve to Answer Machine soon enough and the call was delivered to an agent. However, you also appear to have Background AMD turned ON. That lets the AMD algorithm continue even after the call was delivered to an agent. If POM determines that "Oh, this isn't a person; it's an answering device," then it will take the action that you've specified when you configured Background AMD. As Mike pointed out that can be disconnect, rip the call away from the agent and play a message, or leave the call connected to an agent. You appear to have this set to Disconnect, so the called party and the agent are both disconnected and the call leg to the called party is dropped.

Despite what your customer wants POM to do, there is no way to ensure that every Answer Machine condition (regardless how long it takes to get to that determination) is simply dropped without being connected to an agent. I assume that your Answer Machine action in your strategy just disconnects. With Background AMD on and Disconnect set, the agents will have these answering device calls "ripped away" from them and disconnected as soon as POM makes this determination. You probably already have the "best" configuration to minimize "wasted" agent time and the behavior you report is what I would expect to happen. However, from a called party experience perspective and an agent experience perspective, this may not be desirable. Since AMD is fallible, some people who answer are currently getting your Answer Machine treatment (e.g. disconnect) just as some agents are getting answering device calls that are ripped away and disconnected. Agents typically find having calls ripped away either to leave a message or to be disconnected dissatisfying even if it may "waste less time" than simply having the agent handle these cases by disconnecting or leaving the desired message.

I'd recommend your customer listen to this explanation and decide what is in their best business practice interest. There is little that can be done when a person answered but POM thought it was an answering device. Those called parties will just be hung up on unless some message is left. Realize that this would be a person hearing a message intended for an answering device in the case where POM's AMD got it wrong -- not optimal, but not quite as rude. For the calls delivered to an agent but Background AMD made a delayed decision, agents may find it more acceptable to manually disconnect rather than having the call ripped away.

Hope this explanation helps.

Looks like you are making progress developing your campaigns.

Here are my best answers to your questions:

1. Voice mail box full -- this is NOT a condition that POM can detect. Once the EP call classification has recognized that the call was answered by an answering device, it stops. Therefore there is no reliable method to determine "mail box full." One indication could be that the answering device hung up before the voice message was completely played out. That would require that the VoiceXML application delivering the answering machine message could detect far end disconnect and set a completion code to indicate this. For example, you could look at our INI OutboundStudio product on the DevConnect Marketplace. However, this is at best an indication. If the call classification was wrong and a person answered then simply hung up, that would trigger this behavior. Alternatively, if the answering device played a "Mail box full" message but waited for POM to hang up, you wouldn't get an indication different from having successfully left the message. The only way to reliably determine this condition is to have a person listening and doing the classification. If your campaign was preview, your agents would have to listen to this and could then set an appropriate completion code.

2. Phone number disconnected -- this is one of a number of conditions that are flagged under the Special Information Tone (SIT) category. POM's call classification should flag when it encounters a SIT but all POM knows and reports via a system completion code is SIT. It will not discriminate the specific condition. That is probably adequate for what you are trying to do, but it doesn't discriminate your two examples -- "call can't be completed as dialed" vs "the phone number has been disconnected."

3. Contact Strategy min/max agent configuration -- The min/max agent configuration pertains to the whole campaign. When you run a campaign, POM considers it in the context of what else is going on. Since you have a fixed number of agents, call it N, and possibly several campaigns running, POM first allocates agents to each of the running campaigns until they all have their MIN agent count. If the MIN values add up to more than N, then some campaign will not be able to run until its MIN number of agents are available. Assuming that the sum of the MIN values for the running campaigns is less than N, then POM allocates the remaining agents among the running campaigns based on campaign priority and probably a couple of other variables (see the user doc) until all agents are allocated or a campaign's MAX is reached. In a concrete example, suppose there are two campaigns A & B. A needs 5 agents MIN and only allows 10 agents MAX. B needs 3 agents MIN but allows 20 agents MAX. If A & B are both started, POM will allocate 10 agents to A (more than MIN of 5 but no more than MAX of 10) and 10 agents to B (more than MIN of 3 and the remaining 7 agents which doesn't quite hit the MAX of 13). Final comment: Yes, the user documentation has a tendency to tell you WHAT without sufficient description of WHY. We are continually giving the Avaya POM development team feedback on these things.

Thanks for providing a bit more information, but I think we need to take a slightly different direction with this thread. I broke my first rule in my answers so far. As a software architect, for decades when someone asks me "How do I do X?" my response has been "What are you trying to accomplish?" Although "doing X" may turn out to be the best and most efficient means of accomplishing the goal, it is always best to first understand the goal. Then it is possible to suggest the best solution path, and if X is the best method then at least the description can be tailored to the final goal.

What is the purpose of this POM campaign? It is quite unusual for a POM campaign to call both end users (regular phone numbers) and businesses (I assume that any IVR must be a business number since individuals don't have their personal numbers answered by IVRs). IVR applications typically provide self-service or more commonly menus that direct a caller to the correct agent group. I am going to assume that the purpose for POM to call an IVR would be to navigate to an agent. Is that correct?

Since we are talking about voice calls, POM will either be doing automated voice calling or agent-based calling. Is this POM campaign automated voice or agent-based?

If you can provide an understanding of what this POM campaign is and what it is trying to do, then I may have a few more suggestions. Just realize that calling any ARBITRARY IVR application, listening to and understanding the menu prompts, responding with DTMF to navigate to an end state (self-service or agent) is probably not possible. IVR "intelligence" is not sufficiently advanced that it can successfully recognize AND UNDERSTAND, arbitrary recorded prompts. Some of the cloud ASR providers have very powerful recognition of fairly unconstrained speech. But, "understanding" and interpreting the recognized text is not as advanced. AI machine learning is a mechanism for extracting well developed patterns from input such as the recognized text from a SLM speech recognizer. I'm unaware that anyone has successfully trained an "intent" model that would handle typical IVR menus. That's what would be required to navigate ARBITRARY IVR menu trees.

I'm not sure how much additional help I will be able to give (and in this open forum). You haven't really described your use case in sufficient detail to give other "general" pointers. When the POM campaign reaches an IVR, what is it trying to do? Leave a message? Navigate a "menu" and then connect an agent? These can make a difference in how likely you are to be successful. Also, if you are asking to be able to navigate any arbitrary IVR callflow, that is probably not even theoretically possible to do reliably.

Having one IVR interact with another IVR is always difficult. I know; I've had decades of experience here. In 1989, I put the original AT&T Conversant IVR into the AT&T network to achieve a specific effect. In that case, I was able to persuade the "network IVR" to include DTMF tones in its announcements so that the interaction between the two IVRs was DTMF to DTMF. You won't be able to do that. Using ASR to recognize specific prompts and then sending specific DTMF tones or tone sequences will be difficult -- not necessarily impossible, but difficult.

With regard to how an EP VoiceXML application would send DTMF tones, that should be covered in the developer's guide. In the original Voice Portal, there was no feature to generate tones, but I believe that was added over the years at some point. Prior to that, people recorded DTMF tones and played them as .WAV files. If you end up backed into that corner, be sure that you get accurate DTMF tones generated and then stored as the .WAV files. The specifications for DTMF are quite precise and simply trying to record a device while you press tones is likely to result in recordings that are either not recognized by the IVR's DTMF receiver or not always recognized.

Again, good luck.

Thanks for the clarification of the behavior. As you expected this is NOT what POM should be doing. We have not directly seen this with any of our customers, but a quick search of the Avaya support notes turned up the following that sounds similar:

POM Agent Receives 2 Nailup Calls

Doc ID: SOLN352095;
Version: 3.0

Status: Published;
Published date: 12 Jun 2020;
Updated: 12 Jun 2020

Author: Donna Briggs

Details

AEP 7.2.x POM #.x

Issue with POM placing a second call to an agent
New installation in lab, initial testing of the POM OOTB campaign with the Syntelate desktop

Problem Clarification

Second nailup call to agent within seconds of first nailup call

If you have support with Avaya, I'd suggest opening a ticket and getting Avaya support involved. If you find and read the rest of this support note, you'd find that the problem had to do with a missing EP root certificate:

There was no EP root certificate present in the application trusted store. According to POM documentation, the EP root certificate must be imported into the application server trusted store, which is then the CA certificate for both EPM and MPP. In this case, both MPP and EPM certificates are signed by customer CA. The application server cannot trust the MPP because neither the EP root certificate or the customer CA is present in its trusted store, only the EPM server certicate is there.

I'm not certain that your issue is identical since the duplicated call is coming from Nailer when the only call to the contact should come from PomDriver. That said, there may be another support note that is directly your issue. Regardless, I think a ticket should be opened with Avaya to figure out the cause and fix it.

Good Luck!

I've never actually looked at which processes make which calls, but your observation doesn't surprise me. POM agent-based campaigns always involve a conference between two call legs - one from the MPP to the agent (the "nail-up" connection) and one from the MPP to the contact's phone number (the "called party" connection). When the campaign is Preview, the single call to the contact will originate from the same MPP that is holding up the agent's nail-up connection. The preview call to the contact will be initiated by the agent (or on the agent's behalf via a timer). Although PomDriver could place that call, I can see that the Avaya developers might have chosen to have Nailer place that call. That's an implementation, and not an architectural, detail.

When the campaign is Progressive or Predictive (regardless of the algorithm), Nailer handles the calls to agents but PomDriver handles all of the contact attempts. Further, it isn't restricted to just placing calls from a specific MPP and in fact it doesn't know when a call is launched whether it will be connected to an agent or not nor which agent that might be. The fact that a POM with multiple MPPs is likely to have many (most?) of the called party connections on a different MPP from the nail-up connection that it will be conferenced with is the reason that a 4th "extra" Experience Portal port is provided with each Predictive agent license (1 for nail-up, 2 for outbound calls, and 1 for "transfer"). Once AMD determines the live connect is a person and once an agent is allocated, a SIP transfer from the MPP originating the called party connection to the MPP with the agent nail-up connection occurs.

Based on that description of fundamental POM dialing, what you describe is "expected behavior." What is your "problem?" Is this confusing something you thought you should see differently? In some reporting? If my explanation of how POM works doesn't answer your question, please provide a better description of the "problem" this fundamental behavior is giving you.

You should be able to do what you are describing but it will require a custom application and it may still be a bit tricky. The first thing to recognize is that POM is basically an "IVR that calls a number" instead of an IVR that takes calls. That means that the VoiceXML application invoked by POM can be any IVR application that can be created for the Experience Portal. Assuming you can create an application that can successfully navigate those third party IVR flows, then POM can use that application. Also, if there are multiple IVR flows to navigate, your custom application will have to be able to tell which IVR flow it has to navigate and then do the "correct" things. Although the custom application part will be tricky, there are also the following potential issues.

You should not be surprised that POM classifies the IVR interactions as AM. It is correctly determining that a non-human device answered the call and separating that from a person answering. Since POM makes it easy to do different things for AH and AM, that is actually in your favor. You can have your AH VoiceXML application be different from the "custom" AM application. If this is an agent-based campaign, the AH calls will go to agents and the AM calls will go to your custom app.

There are two cases where you may still have some hurdles to jump. If the campaign is an agent-based campaign and you want the custom application to "navigate" the third party menu tree FOR the agent, I'm not sure how to best do that. Your custom application could transfer to an agent, but that's a slower way to get to an agent than when POM immediately connects an agent to an AH condition.

The second challenge I see is if you need to leave a simple answering machine message on regular answering machines but do the more complicated navigation of third party IVRs. Since you will have to figure out some way to have your custom application know WHICH IVR flow to follow, it may be possible to have it recognize that it was invoked for an answering device that isn't an IVR and to simply play an answering machine message.

Hope this helps and good luck.

Tashiro san,

I'm glad that my posts may be helpful. I can understand your concern about the possible programming complexity and supportability. As I've already confessed, it's been quite a long time since I considered myself a "programmer" (my last programming job used C, a little C++, and Unix shell scripting). Since I don't have a direct feel for how difficult my "suggestions" would be to implement in something like Java, I can't estimate how difficult this might be for you or your customer. I suspect that the Java programmers on our engineering staff wouldn't have any trouble, but we are a development shop and that's basically our business.

Let me offer one final thought. If building an application to mediate getting this information from POM and placing it into appropriate records in the ACRA CRM system could be a problem, I wonder if you might find a solution without building a new integration to POM? If I understood your description correctly, there are existing links in the ACRA system that a user can use to access recordings between a specific "customer" and agents who have spoken with that customer. I assume that today those links to recordings are the result of inbound contact center agent calls being recorded and then a link to the recording somehow being put into the ACRA records. Since the recording system should already have the integration to POM (using the POM Call Recording API), the recording system should already have access to all of the information you are seeking even if they don't do anything with it today. Perhaps the mechanism that currently connects those inbound call recordings to ACRA records could be modified/enhanced to provide the same linkage for the outbound POM calls. If everything is currently being done by the recording vendor, I know that recording vendors usually will entertain building certain forms of "customizations" if asked. If the cost for the recording vendor to provide the capability is acceptable to your customer, that might provide a solution that avoids you, your customer, or a third party software developer from creating and maintaining a new POM-to-CRM system integration.

I hope one of these works. Feel free to update this thread later with some status.

Warm regards,
...glen

Thanks for the background. It is always easier to give a "better" answer to a question when you understand the context.

Let me add a small caveat to my answers. I've been working in this space for "quite a while" ;-). It's been many years since I personally did the actual programming, so my knowledge of the individual API calls, their parameters, etc. is very limited. However, I do try to maintain a reasonable understanding of the architecture and general integration points. That's the basis for any "answers" I give.

If you dig through the Kafka SDK, you may find the info that you are looking for. I don't know one way or the other. However, based on what you have said, it is clear that POM sends the UCID of the desired agent-contact interaction to the recording system when it starts a recording. Let's briefly discuss how that works.

Since all agent-called-party interactions are really a conference (agent nail-up connection with the called-party connection), recording systems have to integrate to the POM Call Recording API (available for download on this website). Call recording systems typically do their recording by monitoring the agent end of all agent calls. If the call recorder simply began recording when the agent nail-up connection started and ended when it droped, the recording would essentially be useless. The agent will have spoken to many people and ALL of that including the silence between conversations would be in that multi-hour recording. The call recording system needs signals (events) to tell it when to start and stop recording each of the individual agent interactions. That's the function of the Call Recording API. The Call Recording API is a bit more complicated than just RESTful web service methods. It's a socket connection, but if you look at the API document, you'll see in the MediaInfo Event that the AgentID, agent extension, UCID, campaign type (progressive or preview), etc. are all provided. That's obviously how the call recordings can have the correct UCID to associate with that specific recording.

If you are unable to locate an easier API method to get the UCID you need, I'd suggest investigating building an interface to the Call Recording API. I don't believe that there would be a problem with more than one "recorder" client using that API, so you should be able to sit in parallel with the actual call recording system. That would allow your integration to harvest the correct UCID from every agent call. Hopefully, the rest of the information in the MediaInfo Event would give you a useful key for storing that UCID back into the customer's CRM system (ACRA). If not, you may be able to use another contemporaneous event, probably from Kafka, to associate the UCID in the MediaInfo Event with the appropriate CRM record. I have no idea how big a programming task this will all turn out to be, but I think this will give you a technically feasible solution.

Your stated goal is to give your agents the "same" screen pop for outbound calls (POM calls) as for inbound calls (probably IVR collects data, puts into UUI, agent desktop uses UUI to "pop" a screen). These are obviously two very different scenarios even though you want your agent experience to be similar (or the same). The key is going to be your agent desktop program.

I don't know what POM compatible desktop you are using, but the key to reaching your goal lies within the capabilities of your desktop. For the inbound case, some identifying info is being associated with the call by being placed in UUI. The agent desktop is using that info in some fashion to pop a relevant screen for this particular caller. The UUI might have been the calling phone number (ANI) or a customer account number, etc. On inbound, you usually have to work harder to find the relevant info for an appropriate screen pop.

For outbound calls, you already have significant information about the called party as contact attributes. Although getting from UUI info to a screen pop isn't the same activity as getting from contact record attribute values to a screen pop, that's what's required to satisfy your goal.

Depending on your desktop, it will hopefully be able to be used for inbound as well as outbound calls. It will need to be "scripted" to approximate the agent screen appearance on POM outbound calls as it would provide to an agent using UUI for inbound calls.

The Custom Class for Post Processing was the original mechanism provided by POM to support users' needs for more information (particularly real-time information) from POM. The CSV file(s) and/or reports that POM provides give the final disposition of contacts and campaigns when the dust settles, but not everything that happened to get there. By building a custom class, a user can tap into the internal event bus and observe ALL of the events occurring within POM as it executes campaign(s). For most users, building this type of processor and "drinking from the event firehose" are more than they wanted. Avaya responded to the desire for less, but more targeted, information by implementing a Kafka event stream. Users can subscribe to the Kafka event feed to more easily get real-time information. Kafka even sorts events out into useful categories so that only relevant events need to be subscribed to. You can probably find the document (11073119 Avaya Proactive Outreach Manager 4.0 Event SDK) providing the Kafka Event SKD on the Internet.

I'm wondering why you are trying to get UCID and AgentID. In the "standard" inbound agent scenario, having those two pieces of info will help you associate a particular caller - agent interaction. That isn't as straightforward with POM. Remember, POM creates a "nail up" connection with the agent. That's a potentially 4-8 hr long "call" that I'm sure is assigned a UCID, but of little value. POM then places calls to contacts. Each of those calls has a UCID, I'm sure, but again the value of that UCID may not be that high. And, finally POM conferences the called-party call with the agent nail-up. What's not obvious in this is how you would find and associate a useful UCID with the agent ID for a specific interaction.

If you are trying to look at specific called-party & agent interactions, there are at least some Kafka events that will give you the phone number called, the "contact record ID," and the agent ID information already associated in a single event. Within the context of POM, it makes more sense to me that you really want to use this association rather than looking for a UCID to pair with an agent ID to make the association on your own.

Hope that helps.

...glen

The performance report table and timeline graph should be understood as providing slightly differently focused views on the performance of your Avaya Experience Portal (EP). In this case, you appear to only be using EP as the host platform for a Proactive Outreach Manager (POM) dialer, but the report is intrinsic to EP and covers all inbound and outbound port activity on the EP. You don’t provide any information about your platform (total number of EP ports, POM licenses & license types, types of campaigns – automated voice, agent-based preview, agent-based progressive/predictive, etc.) Without some of that information, interpretation of this PNG is a bit like reading tea leaves, but I’ll give it a try. ==
Looking at the right & left Timeline Graph axis’ labels, 100% Resource Usage for ports appears to align with a Peak Call Volume of about 45-46 ports. The Timeline peak Outbound Calls (line with inverted triangle markers) only appears to hit about 42-44 calls and reach about 96%-98% port Resource Usage. Notice that there are only 9 marked points on the line graph between 11:00 AM and 11:00 PM. That means that each point represents an average value for about one and a quarter hours. There is one period corresponding to about 2 PM – 4 PM where the system appears to “fully” use all of its ports outdialing. It isn’t 100% for all of that time, but I would estimate that it is as busy as your campaign(s) strategies allow. ==
The table portion of the Performance Report has a bit different interpretation. The Port Utilization % columns are data for the entire 24 hr period that you specified in the report selection criteria. The Peak column indicates that at some (at least one) point during that 24 hr period, your POM campaign(s) did simultaneously use 100% of the EP ports. That would probably occur during an interval whose average was in the high 90’s but not 100%. The Average column indicates that during that 24 hr period, you used 23% of the ports on MPP pom31mpp1py and 22% of the ports on MPP pom31mpp2py. From the Timeline Graph, it is clear that you had no campaign(s) running for several hours prior to 11 AM. When you “include” a large number of zeros in an “average,” you must expect the % to be much lower that if you had selected only a time range when POM campaigns were in full swing. ==
I’m not sure what you were trying to see in this report data, but I hope my “explanation” of how these data should be interpreted will be helpful. If you want to examine actual port usage when your campaign(s) are running, restrict the Performance Report time selection to just those hours. You can drill down quite granularly and get more focused views on what your POM is doing at various times. ==
One final observation on these two forms of the Performance Report. You appear to have no inbound traffic suggestive of an EP/POM only being used as a dialer. There is nothing to prevent you from theoretically also running inbound IVR application(s) on the same platform provided the EP is resourced correctly. Any EP platform running exclusively inbound applications with this type of port usage data would be a system in serious need of additional ports. When utilization is this high, basic traffic theory would predict that the “turn away” probability (IVR calls receiving busy signals) would be quite high! Should you choose to add inbound, you will need to examine this report and a few others quite carefully to ensure that outbound port occupancy by POM is not conflicting with or “starving” inbound port requirements.