---
title: Customer Provider types
slug: contact-center/customer-provider-types
docTags: 
createdAt: 2025-10-15T07:20:10.911Z
---

# Overview

Customer Providers define the strategy for sourcing, prioritizing, and managing customer contact numbers for dialing campaigns. The system supports various providers, each designed for specific outbound campaign goals and complexity levels, including **Campaign Based**, **Lead Based**, and the advanced **PACE Based** Customer Provider.

## 1. Campaign Based Customer Provider

This provider focuses on managing the customer cache size and the order in which customers are fetched from the database for dialing.

### Parameters

- **minCacheSize**: This parameter sets the minimum threshold. If the total numbers present in the cache are less than this minimum value, numbers will be fetched from the database and stored in the cache.
- **fetchSize**: This specifies the total number of customers to be fetched at a time for this campaign.
- **fetchRandomCustomers**: This parameter has been **Deprecated** from release 3\_02.40 onwards. If enabled, customers will be fetched from the database in random order. However, this is not preferred because it will slow down fetching.
- **fetchOrderPolicy**: Customer numbers will be fetched in the configured order. Fetch Order can be **FIFO**, **LIFO**, **RANDOM**, **NO\_ORDER**, **ATTEMPT\_ASC**, **ATTEMPT\_DESC**, **DATA\_TABLE\_ASC**, or **DATA\_TABLE\_DESC**. This functionality is a **Licensed feature** (**allowFetchOrder**).
- **fetchOrderColumnName**: This field is only applicable if **DATA\_TABLE\_DESC** or **DATA\_TABLE\_ASC** is selected in the fetch order policy. It specifies the column name which will be used for sorting customers while dialing.

## 2. Lead Based Customer Provider

The Lead Based Customer Provider is used for dialing customers according to their **lead priority**. Customers with high priority will be dialed first, followed by customers of lower priority. If two leads have the same priority, numbers will be dialed according to their weights.

### Recommended For

- Scenarios where leads must be processed equally (leveled) at any given time.
- **Parallel Predictive Dialer (PPD)** campaigns, as it is recommended to maintain a cache per lead so that all queues get sufficient numbers, if available.
- Campaigns utilizing lead to user mapping.

## 3. PACE Based Customer Provider

### What is PACE?

**PACE** (**P**ro **A**ctive **C**onnect **E**nhancer) is a customer provider. The PACE Customer Provider, together with Ameyo's Predictive Dialer, forms the **PACE Solution**. It is responsible for maintaining the cache from which the dialer can pick customers and dial.

### When to Use PACE?

PACE should be used when **customer behavior is known** to the industry beforehand. By analyzing this behavior, rules can be written that PACE uses to increase the overall productivity of the contact center.

### Business Use Cases

1. **Business Usecase 1 (Targeted Redialing):** If a **CONNECTED** call is a SALE, customers with system dispositions like **FAILED**, **AMD**, or **PROVIDER\_FAILURE** are known to exhibit specific behavior. Using PACE, you can restrict the dialer from calling such customers again (or dial them less frequently), which conserves bandwidth and prevents a decrease in the speed of profit. Conversely, you can force **CONNECTED** numbers to be dialed again if the contact center requires it.
2. **Business Usecase 2 (State-Based Dialing Strategy):** In Collection or Sales scenarios, the process of converting a customer requires an attached dialing strategy. This strategy can be broken down into **states** that are attached to the customer as rules are executed. For example: If a customer is not picking up the call at 9 am (state: **OfficeTravelling**), the rule can be: If (SYSTEM\_DISPOSITION='NO\_ANSWER' OR SYSTEM\_DISPOSITION ='PROVIDER\_TEMP\_FAILURE' ) then CallAroundTime='05:00:00' and NotCallBefore='04:00:00'.

### Categorization of Customers (States)

PACE categorizes customers into groups called **states** where the customer's behavior is known. These states are defined by the client, and a specific dialing percentage can be defined for them.

For example, numbers with a system disposition of **FAILED** can be grouped into a state called **BAD**, other customers into a **GOOD** state, and customers not yet dialed into **FRESH\_CUSTOMERS**. A sample dialing percentage could be: **freshCustomers (40%)**, **GOOD (50%)**, and **BAD (10%)**.

After the first attempt, the system knows the customer's state, and PACE will try to follow the dialing percentage. If there are 100 agents, the dialer will pick numbers in that ratio (40 fresh, 50 good, 10 bad) when all agents are idle and dial.

To define these states, select the customer provider in **Advance settings** for the campaign, then go to the **supervise view** and under **dialer settings**, define states in the lower-left area.

### Rules

PACE works on the category of customers, and these categories are maintained by **PACE Rules**. All customers start with a **CONNECTION\_STATE** of 'freshCustomer'.

- **Simple Pace Rule:** An example rule is: if system\_disposition is FAILED and CONNECTION\_STATE='freshCustomer' then TARGET\_CONNECTION\_STATE='BAD'.
  - **NCB (Not to Call Before):** A timestamp that means the customer will not be dialed before this time.
  - **CAT (Call Around Time):** A timestamp around which the customer will be dialed. *Note: This is not enforced; it depends on various factors.*
- **Complex Pace Rule:** Involves uploading a JavaScript file where the entire logic is written (e.g., as written for TATA SKY).

Rules are created under the **Customers** tab in the manage view and then assigned to the campaign.

