> For the complete documentation index, see [llms.txt](https://atlas.anywhere.now/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://atlas.anywhere.now/contact-center-configuration/service-and-contact-center-settings.md).

# Service and Contact Center Settings

Configure the endpoints and core contact-center settings that control routing, queueing, and feature behavior.

Review these settings before you build queues, interactive voice response (IVR) branches, and routing rules. They define how the contact center receives conversations and how core callflow behavior is applied.

Use this page as the first Administration stop after Initial Setup and OnePortal provisioning. Before you configure branch-specific behavior, confirm the Service and Contact Center (UCC) exist, then use these settings to understand the endpoint, routing, queueing, and feature assumptions that the rest of the contact-center configuration depends on.

{% content-ref url="/spaces/8itFXJdndqu1dclywEFc/pages/X8M0XGtscQpBWEtjW1aL" %}
[Setup overview](/set-up-dialogue-cloud-neo/initial-setup.md)
{% endcontent-ref %}

{% content-ref url="/spaces/8itFXJdndqu1dclywEFc/pages/WFwwDLcdF56gXpYI8oHW" %}
[View and edit Contact Centers (UCCs)](/onboard-or-upgrade/onboard-new-customer/view-all-uccs.md)
{% endcontent-ref %}

## Prerequisites

Before you review these settings, make sure:

* the service and contact center already exist
* you know which endpoints are already assigned to the contact center from [View and edit Contact Centers (UCCs)](/onboard-or-upgrade/onboard-new-customer/view-all-uccs.md)
* you know which routing, queue, and quality-monitoring behaviors the contact center needs
* the setup decisions from [Onboard a new customer](/onboard-or-upgrade/onboard-new-customer.md) are complete for this tenant

## Endpoint types

Each contact center uses a mix of required endpoints and optional entry points.

| Endpoint type            | Purpose                                                                                                         |
| ------------------------ | --------------------------------------------------------------------------------------------------------------- |
| `SystemEndpoints`        | Internal endpoints used for platform-controlled call handling such as hunts, transfers, and supervisor behavior |
| `MainEndpoint`           | Primary entry point for the contact center                                                                      |
| `DefaultRoutingEndpoint` | Internal endpoint used when routing rules need a routing target                                                 |
| `ModalityEndpoints`      | Additional entry points used for alternate numbers, side-entry routing, or special opening behavior             |

{% hint style="warning" %}
Do not remove or repurpose the required technical endpoints. They are critical to UCC operation.
{% endhint %}

## Common endpoint scenarios

Use additional endpoints when you need to:

* start a caller at a specific IVR branch
* route a caller directly to a skill queue
* add another number to the same contact center
* give one entry point higher priority than normal queue traffic
* with Connect, allow an eligible side-entry endpoint to bypass normal Business Hours and Holidays

Create endpoints in OnePortal, the Dialogue Cloud administration portal.

## Endpoint fields to review

| Field                  | Why it matters                                                                                                                                                                                                                                                    |
| ---------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `Title`                | Identifies the endpoint record                                                                                                                                                                                                                                    |
| `Skill`                | Sends the endpoint directly to a queue                                                                                                                                                                                                                            |
| `ParentQuestion`       | Starts the caller at a specific IVR branch                                                                                                                                                                                                                        |
| `Priority`             | Lets one entry point bypass normal queue order                                                                                                                                                                                                                    |
| `EnableRouting`        | Applies routing-list behavior to that endpoint                                                                                                                                                                                                                    |
| `Always open`          | Connect: lets a side-entry endpoint bypass Business Hours and Holidays for incoming voice calls. Unify: does not bypass the UCC opening-hours check.                                                                                                              |
| `Hide`                 | Removes the endpoint from selection surfaces where it should not be used interactively                                                                                                                                                                            |
| `Show Agent Caller ID` | Lets WebAgent dialpad or embedded CTI WebAgent click-to-dial calls dial out with the agent caller ID when the supported endpoint design allows it. This is available for Dialogue Cloud Neo (Connect) on the Microsoft Connect model with SBC and Direct Routing. |

{% hint style="info" %}
With Connect, **Always open** does not override `TemporarilyClosed` or overflow checks. Other routing and flow-entry conditions still apply. With Unify, a closed UCC plays the configured closed message and ends an incoming voice call before starting Dialogue Studio. See [Business Hours and Holidays](/contact-center-configuration/building-your-callflow/business-hours-and-holidays.md#connect-and-unify) for the connect-model differences.
{% endhint %}

{% hint style="info" %}
Endpoint priority can be applied to a skill or IVR parent question, but it is not available in combination with Dialogue Studio flows. If a design needs priority handling and Dialogue Studio, confirm the routing pattern before configuring the endpoint.
{% endhint %}

## Settings groups that affect caller handling

The following settings are grouped by the contact-center behavior they control.

### Hunting and presence behavior

Review these settings before finalizing skills and routing. They belong with the queue and skill design because they affect which agents can receive a dialogue and in what order.

For a shorter routing-focused view of these dependencies, see **Skills and routing criteria**.

{% content-ref url="/pages/qws5JKHo8p4uIh5RxAd7" %}
[Configure skills and routing criteria](/contact-center-configuration/queues/skills-and-routing-criteria.md)
{% endcontent-ref %}

| Setting                   | What it controls                                                                             | Configuration note                                                                                                                                                               |
| ------------------------- | -------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `HuntingMethod`           | How the platform chooses between eligible agents.                                            | Default `LongestIdle`. Choose the method together with the skill design. See [Skills and routing criteria](/contact-center-configuration/queues/skills-and-routing-criteria.md). |
| `HuntingPresenceOrder`    | Which presence states are preferred first when multiple agents are eligible.                 | Default order: `Available` > `Busy` > `Away` > `Offline`. Keep the order aligned with the customer's Microsoft Teams presence and wrap-up behavior.                              |
| `LowestHuntPresence`      | The lowest presence state that is still eligible for hunting.                                | Default `Available`. Supported values include `Available`, `Away`, `Busy`, and `Offline`; confirm forwarding and routing behavior before using `Offline`.                        |
| `IgnoreSkillValues`       | Whether score-based ordering should be skipped.                                              | Default `False`. When set to `True`, the hunting method decides between eligible agents without using skill scores for ordering.                                                 |
| `MaxReservations`         | How many agents can be reserved at the same time.                                            | Default `2`; maximum `4`. For parallel hunting, this applies only to supported Connect direct-to-Teams-client scenarios; validate endpoint capacity before increasing it.        |
| `WaitForAgentBusyTimeout` | Controls how long the UCC waits for the hunted agent to become Busy after the agent accepts. | Default `90` seconds. Do not use high workaround values unless support confirms the presence-transition issue and operational impact.                                            |

Configure these values in the contact-center settings source approved for the environment. For SharePoint-backed configuration this is the UCC configuration settings list; for cloud-managed environments, use the delivery or support-owned configuration path.

Skill scores are evaluated before the hunting method, except for `RoundRobin`. `RoundRobin` and `Parallel` are not currently available for the Unify connect model.

{% hint style="warning" %}
Parallel hunting is not supported in WebAgent with either the Connect or Unify connect model. It is also unavailable for Attendant Console for Dialogue Cloud call handling.
{% endhint %}

Parallel hunting applies only to supported Connect direct-to-Teams-client audio-call scenarios. If `HuntingMethod` is set to `Parallel`, confirm the endpoint design with support; the legacy source limits parallel hunts to a maximum of four agents and requires enough system endpoints for that hunt width.

### Contact-center timezone

Each UCC can have its own timezone. The timezone affects business hours, holidays, and CDR database timestamps. For SharePoint-backed UCC configuration, the timezone comes from the UCC site's regional settings.

Changing the UCC timezone requires a UCC Service restart, which interrupts every UCC hosted by that service. Plan timezone changes during a maintenance window and confirm the impact with the service owner before applying them.

### Reservation point system

Use the reservation point system when agents should be able to handle a controlled combination of audio and text dialogues instead of a fixed one-dialogue-at-a-time model.

The point system uses these rules:

* an agent has a capacity of 100 points
* each dialogue modality can consume a configured number of points
* an agent is not hunted for a new dialogue when accepting it would exceed the configured capacity for that UCC

For example, if audio consumes 80 points and text consumes 20 points, an agent can handle one audio dialogue and one text dialogue, or several text dialogues, depending on the active dialogues and the UCC configuration.

Configure the behavior by setting `ReservationSystem` to `PointSystem` and setting the points per dialogue on each modality with `wsp_ucc_PointsPerSession`. If `ReservationSystem` is empty, legacy behavior is assumed. Default `Legacy`.

{% hint style="info" %}
Active dialogues are tracked globally for the agent, but the number of points consumed by each dialogue is calculated from the UCC where that dialogue takes place. If an agent belongs to multiple UCCs with different point settings, validate the combined behavior before using the point system in production.
{% endhint %}

### Agent accept with DTMF

Use agent accept with DTMF when an agent must explicitly confirm a hunted audio call before being connected to the customer. This is typically used when an agent may answer on a mobile phone, or when callback or dialer scenarios require the agent to review context before accepting the customer conversation.

For the broader caller and dialer design, see **Callback journeys**.

{% content-ref url="/pages/exG2JtyGssxhoZAHsZeq" %}
[Callback journeys](/contact-center-configuration/building-your-callflow/callback-journeys.md)
{% endcontent-ref %}

When this behavior is enabled:

1. The UCC hunts an available agent.
2. The agent answers the hunted call.
3. The UCC plays the configured accept prompt.
4. The agent presses the configured DTMF choice.
5. The agent is connected to the customer.

Review these settings together:

| Setting                       | Use                                                                                                               |
| ----------------------------- | ----------------------------------------------------------------------------------------------------------------- |
| `AgentAcceptWithDTMFEnabled`  | Enables DTMF confirmation for the agent accept flow. Default `False`.                                             |
| `AgentAcceptWithDTMFChoice`   | Defines the DTMF digit the agent must press to accept. Default `1`.                                               |
| `AgentAcceptWithDTMFTimeOut`  | Defines how long the UCC waits for the agent's DTMF choice before continuing the hunt flow. Default `10` seconds. |
| `AgentAcceptDTMFPlayListName` | Defines the playlist played to the agent during the accept prompt.                                                |

{% hint style="warning" %}
Validate this behavior with the customer's hunting model before enabling it. The Core implementation applies the accept-by-DTMF path to non-parallel hunts; if the UCC uses parallel hunting, confirm the expected behavior with support.
{% endhint %}

### Hunt BlockList

Use the Hunt BlockList when agents who appear eligible for hunting should be temporarily excluded after specific hunt outcomes. This can prevent repeated hunts to an agent who is temporarily unavailable because of timeout, decline, voicemail forwarding, or a temporary-unavailable response.

Review these settings together:

| Setting               | Use                                                                                                                                                                                                                      |
| --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `BlockAgentTriggers`  | Comma-separated list of conditions that add an agent to the BlockList. Supported trigger values include `None`, `HuntTimeout`, `Decline`, `UmVoicemail`, `DoNotDisturb`, `TempUnavailable`, and `Other`. Default `None`. |
| `UnblockAgentTimeout` | Number of seconds before the agent can be removed from the BlockList for `HuntTimeout`, `Decline`, and `UmVoicemail`. Default `0`; use `0` when removal should depend on presence change instead of a timer.             |

Agents can be removed from the BlockList when the platform detects a presence change that makes the agent eligible again. For `DoNotDisturb` and `TempUnavailable`, use presence change as the removal path.

{% hint style="warning" %}
BlockList behavior directly affects which agents can receive hunts. Test each configured trigger and removal path with representative agent states before enabling it in production.
{% endhint %}

### Queue behavior

These settings shape what callers experience while waiting:

* `SchedulingAlgorithm` controls how queued dialogues are ordered for hunting
* `ServiceLevelAgreementGoalInSecondsDefault` provides the fallback SLA goal when SLA-based scheduling is used
* `OverflowThreshold` controls when overflow behavior applies
* `OverflowThresholdAlgorithm` controls whether overflow uses a fixed threshold or a threshold based on active agents
* `OverflowActiveAgentsRatio` controls the dynamic overflow threshold when the active-agent algorithm is used
* `QueueBusyTimeOut` controls when the extra busy message is introduced
* `QueueBusySpeechWaitTimeout` controls the delay between queue prompts
* `QueueNoChoiceTimeout` controls when the platform disconnects after no IVR input
* `DisablePreviousPlayListPositionQueue` controls whether queue playback restarts or continues where it left off

Use `SchedulingAlgorithm` with `FirstInFirstOut` when dialogues should be offered in queue-entry order. Use `ServiceLevelAgreement` when dialogues should be offered by SLA urgency. Priority is evaluated before the configured scheduling algorithm, and FIFO is used as the fallback when dialogues from UCCs with different scheduling algorithms must be compared.

When SLA scheduling is used, configure at least one SLA goal source: skill, modality, or `ServiceLevelAgreementGoalInSecondsDefault`. Skill-level SLA goals take precedence over modality goals, and modality goals take precedence over the default setting.

Use `OverflowThresholdAlgorithm` with `StaticThreshold` when overflow should start at a fixed queue length. Use the active-agent threshold algorithm only when overflow should scale with the number of active agents for the skill. Validate the resulting threshold with representative staffing levels before production use.

Default values from the source include `OverflowThreshold = 999`, `QueueBusyTimeOut = 60`, `QueueBusySpeechWaitTimeout = 5`, and `QueueNoChoiceTimeout = 360`.

### IVR and speech behavior

These settings affect how the IVR sounds and responds:

* `CultureInfo` controls text-to-speech language
* `SpeechProvider` selects the text-to-speech provider
* `SpeechPreferredVoiceName` selects the preferred voice when the provider supports it
* `DtmfSortingOrder` controls the order in which IVR choices are presented
* `PinCode` can require keypad input after the welcome message
* `LastQuestionSpeechWaitTimeout` controls how quickly the IVR repeats a question

Supported speech-provider values include `MicrosoftSpeechSynthesizer`, `MicrosoftCognitiveServices`, and `GoogleCloudTextToSpeechV1`. The locally installed `MicrosoftSpeechSynthesizer` is the fallback if a configured cloud provider cannot initialize. Cloud providers can be used for selected queue, callback, and Dialogue Studio voice prompts; confirm supported prompt types, credentials, and cost impact before enabling them.

For `MicrosoftCognitiveServices`, review `SpeechMicrosoftCognitiveApiKey`, `SpeechMicrosoftCognitiveApiEndpoint`, and `SpeechMicrosoftCognitiveApiAuthorizationEndpoint`. For `GoogleCloudTextToSpeechV1`, review the `GoogleAppCredentialsJson` plugin setting in the `TextToSpeech` scope.

Default values from the source include `CultureInfo = en-US`, `DtmfSortingOrder = 1234567890*#`, and `LastQuestionSpeechWaitTimeout = 5`.

### Routing and transfer behavior

These settings affect routing lists and transfers:

* `EnableRoutingOutsideBusinessHours` determines whether routing rules also apply when the contact center is closed
* `TransferTimeout` controls how long a transfer attempt can wait
* `EnableTransferSuccessfulNotification` and `TransferSuccessfulNotificationTts` control post-transfer notifications
* `UseImpersonation` affects which caller identity is shown during hunting, transfers, and forwards
* `UseTeamsHunter` selects the Teams hunter path for environments that require Teams-based hunting behavior
* `TeamsAnonymousImpersonateUri` supplies the impersonation URI used by the Teams hunter for anonymous or federated scenarios where that behavior is approved

`TransferTimeout` defaults to `30` seconds. `EnableTransferSuccessfulNotification` defaults to `False`; when enabled, the platform can play a default beep or the text in `TransferSuccessfulNotificationTts`, which defaults to empty. `UseImpersonation` defaults to `False`; validate caller identity through hunts, transfers, and forwards before changing it.

`AudioDuringForward` controls what the caller hears during forward behavior. Supported source values are `DialTone`, `Playlist`, `Queue`, and `Silent`; default `DialTone`. `DisconnectAfterUnsuccessfulTransfer` controls whether a failed transfer disconnects the call; default `False`.

### Quality monitoring and hold behavior

These settings affect post-call feedback and waiting behavior:

* `UseQualityMonitor` enables post-call quality questions for inbound audio conversations
* `UseQualityMonitorWithOutboundDefault` enables quality monitoring after intercepted outbound conversations
* `QualityMonitorNoChoiceTimeOut` controls the response timeout for quality questions
* `OnHoldPlayList` and `QueuePlayList` define which playlists are used while a caller is waiting or on hold

### Wrap-up and agent-state behavior

These settings affect agent availability after a dialogue and operational feedback while changing state:

| Setting                     | Use                                                                                                 | Value guidance                                                                                                     |
| --------------------------- | --------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------ |
| `DischargeDuration`         | Defines how many seconds before a new call can be offered to an agent after the previous call ends. | Default `1`.                                                                                                       |
| `DischargeDurationInterval` | Defines how many seconds are added when an agent increases wrap-up time.                            | Default `10`; `0` prevents increasing wrap-up time.                                                                |
| `UseOutboundWrapUp`         | Controls whether outbound conversations also create wrap-up time.                                   | Default `False`. Requires the outbound call path and recording/interception behavior approved for the environment. |

For Teams presence behavior during wrap-up, see [Configure Microsoft Graph Presence](/set-up-dialogue-cloud-neo/prerequisites/configure-microsoft-graph-presence.md).

## Verification

After reviewing these settings:

1. Confirm the required endpoints are still present.
2. Confirm any routing-enabled endpoint has the intended skill or IVR target.
3. Confirm the queue, routing, and quality-monitoring settings match the contact-center design.
4. Test one call path that uses the main endpoint and one call path that uses a special endpoint.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://atlas.anywhere.now/contact-center-configuration/service-and-contact-center-settings.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
