本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# Amazon Connect 對外行銷活動的最佳實務
本節中的主題說明對外行銷活動的最佳實務。這些實務準則可提高客服人員生產力、協助您遵循法規，且有助於保護電話號碼的完整性。
**Topics**
+ [選擇語音通訊適合的模式](#right-campaign-for-vc)
+ [語音通訊的客服人員配置最佳實務](#agent-staffing-vc)
+ [連線延遲最佳實務](#call-latency-oc)
+ [答錄機偵測的最佳實務](#machine-detection-oc)
+ [將已排序的客群與對外行銷活動和旅程搭配使用](#sorted-segments-best-practices)
## 選擇語音通訊適合的模式
Amazon Connect 對外行銷活動提供了數種類型的語音通訊。以下幾節將說明各種類型，讓您能夠實作最符合自身需求的行銷活動。
**Topics**
+ [預測 (客服人員輔助語音)](#predictive-campaigns-oc)
+ [漸進式 (客服人員輔助語音)](#progressive-campaigns-oc)
+ [無客服人員 (自動語音)](#agentless-campaigns-oc)
### 預測 (客服人員輔助語音)
若客服人員生產力、每次通話成本或聯絡中心效率是關鍵指標，請使用預測模式。預測模式預期將有許多通話不會被接聽。為了平衡這一點，它們會藉由預測客服人員的可用性，在客服人員當值期間盡可能撥打清單中的電話號碼。
預測演算法會根據特定效能指標預先撥打電話。這表示，在客服人員有空，且客戶接通下一個有空的客服人員之前，即可接通電話。預測演算法會持續即時分析、評估和預測客服人員可用性，以提升客服人員的生產力和效率。
### 漸進式 (客服人員輔助語音)
若您需要降低接聽速度，請使用漸進模式。
漸進模式行銷活動會在客服人員完成先前的通話後，撥打清單中的下一個電話號碼。如果有多個行銷活動以同一組客服人員為目標，則每個客服人員最終可能會撥打相同客服人員的聯絡人。有兩種方式可以預防此狀況：
+ 變更行銷活動的頻寬分配，讓每個行銷活動的頻寬分配總和小於或等於 100%。這樣可以大幅降低多個行銷活動對相同客服人員撥打聯絡人的可能性，但無法完全消除。
+ 若要保證能夠一對一，則每個行銷活動必須要有一組專屬的客服人員。若要這麼做，請將行銷活動的佇列指派給單一轉接設定檔。該轉接設定檔必須只有此行銷活動的佇列、必須僅允許語音通話，且不應將任何撥入聯絡放入此佇列中。
您可以利用整合式答錄機偵測來識別真人客戶接聽或語音信箱，並據以自訂您的聯絡策略。例如，如果某人接聽通話，您可以提供選項讓他們選取。如果通話進入語音信箱，您可以留言。
您也可以藉由指定每個行銷活動的容量來管理步調。例如，您可以為指定的無客服人員行銷活動設定比其他撥號程式行銷活動更高的容量，藉此以較快的速度傳送更多語音通知。
### 無客服人員 (自動語音)
您可以使用無客服人員模式傳送大量的個人化語音通知、預約提醒，或使用互動式語音回應 (IVR) 啟用自助服務，而不需要客服人員。
## 語音通訊的客服人員配置最佳實務
通話接收者在接聽通話時若沒聽到對方的聲音，通常會掛斷電話。對於預測模式，請利用下列最佳實務來避免這種沉默的情況：
+ 確定您有足夠的客服人員登入通話佇列中。如需人員配置的詳細資訊，請參閱 [Amazon Connect 中的預測、容量規劃和排程](forecasting-capacity-planning-scheduling.md)。
+ 考慮使用 Amazon Connect 的機器學習服務。
+ [預測](forecasting.md)。根據歷史資料分析和預測接觸量。未來的需求 (聯絡人數量和處理時間) 是什麼樣子？ Amazon Connect 預測可提供準確且自動產生的預測，並且每天自動更新。
+ [容量規劃](capacity-planning.md)。預測您的客服中心需要多少專員。依據案例、服務層級目標和指標 (例如收縮) 來優化計畫。
+ [排程](scheduling.md)。針對彈性的日常工作負載產生客服人員排程，並符合業務和合規性需求。為客服人員提供彈性時間表和工作生活平衡。每次輪班需要多少位客服人員？ 哪個客服人員在哪個時段中工作？
[排程遵循](schedule-adherence.md)。讓聯絡中心主管能夠監控排程遵循情況，並提高客服人員的生產力。發布客服人員排程後，即可使用排程遵循指標結果。
## 連線延遲最佳實務
成功的外撥通話行銷活動可避免通話沉默，也就是在對方接聽通話後，客服人員上線之前無人說話的期間。限制沉默或捨棄通話次數並告知受話方的法律要求也可能適用。您可以透過不同的方式設定 Amazon Connect，以降低通話連線延遲。
**Topics**
+ [外撥真人客服人員通話](#outbound-agent-staffed-oc)
+ [外撥無客服人員通話](#outbound-agentless-oc)
+ [低語和佇列流程最佳實務](#whisper-and-queue-oc)
+ [使用者管理最佳實務](#user-admin-oc)
+ [工作站和網路最佳實務](#workstations-oc)
+ [測試最佳實務](#testing-oc)
### 外撥真人客服人員通話
使用 [檢查通話進度](check-call-progress.md) 流程區塊時：
+ 來電已接聽分支 - 移除 [檢查通話進度](check-call-progress.md) 與 [轉接至佇列](transfer-to-queue.md) 區塊之間的所有流程區塊。這樣可以盡可能縮短從撥號方說出「您好」到客服人員接聽之間的延遲。
+ 未偵測到分支 - 此分支應視同轉接至 [轉接至佇列](transfer-to-queue.md) 區塊的「來電已接聽」來處理。當 ML 模型無法分類接聽類型時，就會使用此分支。由於這有可能是語音信箱或真人通話，若有語音信箱表明可以留言，您可以在**轉接至佇列**區塊之前播放訊息。
例如，「這是 Example Corp. 來電確認您的預約。我們不知道這是您本人還是語音信箱在接聽此通話。請別掛斷，將有客服人員與您通話。」
### 外撥無客服人員通話
Outbound Campaigns 常會使用自訂問候語和自助服務功能。請勿使用 Lambda 函數來取得客戶設定檔資料。反之，請使用下列方法從客戶設定檔擷取資料：
+ 在流程開始時新增**客戶設定檔**區塊，然後選取**取得設定檔**動作。
+ 將識別符類型設定為**設定檔 ID**。
+ 使用 `$.Attributes.connect_customer-profile_profile-id`做為識別符值。從使用客戶設定檔區段的對外行銷活動撥打聯絡人時，會自動填入此屬性。
+ 選取要擷取的適當回應欄位。對於標準設定檔屬性 （例如 FirstName、LastName)，請直接新增它們。對於自訂屬性 （例如 AppointmentDate、AppointmentTime)，選取自訂屬性將其新增為自訂回應欄位。
+ 在客戶設定檔區塊之後，您可以使用 `$.Customer.` 存取設定檔屬性的標準屬性或`$.Customer.Attributes.`自訂屬性，以播放自訂問候語。
以下是如何在提示中使用客戶設定檔屬性的範例：
+ 範例 -「來電已接聽」或「未偵測到」：「您好，`$.Customer.FirstName`。這是 【您的組織】 呼叫 以確認您即將`$.Customer.Attributes.AppointmentDate`在 的預約`$.Customer.Attributes.AppointmentTime`。如果這仍是您可接受的日期和時間，請說「確認」即可。如果您想要使用我們的自助服務系統修改預約，請說「自助服務」即可，或者別掛斷電話，我們將為您轉接有空的客服人員。」
+ 範例 - 有嗶聲或沒有嗶聲的語音信箱：「您好，`$.Customer.FirstName`。這是 【您的組織】 呼叫 以確認您即將`$.Customer.Attributes.AppointmentDate`在 的預約`$.Customer.Attributes.AppointmentTime`。如果這仍是您可接受的日期和時間，我們到時候見。如果您想要修改預約時間，請經由 `$.SystemEndpoint.Address` 回電重新安排預約時間」
+ 錯誤分支 - 有時可能會發生問題，導致通話進入錯誤分支。最佳實務是使用 [播放提示](play.md) 區塊，提供已撥打的聯絡適用的訊息，並指示「請經由 `$.SystemEndpoint.Address` 來電確認或重新安排預約時間。」 在 [中斷連線 / 掛斷](disconnect-hang-up.md) 區塊之前執行此操作，以防通話接收者已接聽，但在處理過程中發生錯誤。
### 低語和佇列流程最佳實務
+ 從**預設客戶佇列**流程中移除**循環提示**，並將其取代為**結束流程/繼續**。
+ 如果客服人員未在通話進入佇列的 2 秒內接聽，您可以使用**循環提示**盡可能避免沉默通話，並且為客戶播放訊息。下圖顯示具有循環提示的一般流程區塊。
+ 使用 [設定低語流程](set-whisper-flow.md) 區塊上的**停用客服人員低語**和**停用客戶低語**選項。如此，客戶在對外行銷活動的過程中會感受到較低的連線延遲。下圖顯示**停用客服人員低語**設定在區塊屬性頁面上的位置。
### 使用者管理最佳實務
建議您為使用者設定下列選項，以縮短連線時間。若要存取這些設定，請在 Connect Customer 管理員網站導覽至**使用者**、**使用者管理**、**編輯**。
這些選項僅適用於軟體電話。
+ [啟用自動接受通話](enable-auto-accept.md)。這樣可以縮短受話方接聽後通話連線延遲的可能性。
+ [將聯絡後工作 (ACW) 逾時設定為](configure-agents.md) 30。將 ACW 時間降至最低，可將使用預測撥號行銷活動時的撥號演算法最佳化。
+ [啟用持續連線](enable-persistent-connection.md)。這樣可以在通話結束後保有客服人員連線。它可加快後續通話的連線速度。
下圖顯示**編輯使用者**頁面的**設定**區段。
### 工作站和網路最佳實務
下列最佳實務可確保有足夠的硬體和網路資源，因而有助於最佳化客服人員的效率。
+ 確定客服人員工作站符合最低需求。如需詳細資訊，請參閱[使用聯絡人控制台 (CCP) 的客服人員耳機與工作站需求](ccp-agent-hardware.md)。
+ 確定客服人員已開啟 CCP 或客服人員工作區，並位於其桌面上。這樣可以縮短在問候來電者之前顯示畫面所耗費的時間。
+ 請確定客服人員會使用有線網路連線。這樣可以降低潛在的無線網路延遲。
+ 如果可能，請將託管 Amazon Connect 執行個體 AWS 的區域與與對外行銷活動互動的客服人員之間的地理距離降至最低。客服人員與託管區域之間的地理距離越大，可能的延遲就越高。
**注意**
Outbound Campaigns 在客服人員可撥打的號碼方面有所限制，具體取決於 Amazon Connect 執行個體的來源。如需詳細資訊，請參閱 [Amazon Connect 電信國家/地區覆蓋指南](https://d1v2gagwb6hfe1.cloudfront.net/Amazon_Connect_Telecoms_Coverage.pdf)。
### 測試最佳實務
最佳實務是大規模執行測試。為了達到最低的通話連線延遲，請使用對外行銷活動進行數十萬次連續通話，以模擬您的生產環境。進行少量行銷活動通話時，通話連線延遲可能相對較高。
## 答錄機偵測的最佳實務
若要在行銷活動中使用答錄機偵測 (AMD)，請使用 [檢查通話進度](check-call-progress.md) 流程區塊。此區塊提供通話進度分析。這是一種 ML 模型，可偵測接聽通話的情況，以便您為真人接聽的通話和機器接聽的通話提供不同的體驗 (無論是否發出嗶聲)。當 ML 模型無法區分真人和語音信箱，或通話處理發生錯誤時，此流程區塊也提供轉接通話的分支。
AMD 使用下列條件來偵測即時通話：
+ 與預先錄製的訊息相關聯的背景雜訊。
+ 較長的字詞字串，例如「您好，抱歉我無法接聽您的來電。請在...之後留言」
+ 真人來電者說出類似「您好，您好？」的內容後，接著只有問候語之後的沉默。
撥打給消費者的通話，有 40% 到 60% 會轉接到語音信箱。AMD 有助於減少即時通話中的語音信箱通話數量。不過，偵測準確性有其限制。
+ 如果語音信箱問候語是簡短的「您好」，或是有頓挫，AMD 會將其偵測為真人客戶 (誤判為否)。
+ 真人客戶的問候語如果較長，有時會被錯誤地偵測為語音信箱 (誤判為真)。
+ 系統將通話連線至客服人員時會有一小段延遲，這可能會導致客戶掛斷電話。
+ 不支援具有多層級語音信箱提示的 PBX (專用交換機) 號碼。
### 答錄機偵測的優點、缺點和最佳用法
使用答錄機偵測 (AMD) 可能不符合電話行銷法規。您有責任以符合相關法規的方式實作 AMD，且務必向法務顧問諮詢特定使用案例。
使用案例 1：AMD 開啟，並留下自動語音信箱訊息
+ **優點** – 客服人員 95% 的時間都在與即時通話互動，通話時間得以最大化。AMD 可在偵測到語音信箱時留下自動語音信箱訊息。
+ **缺點** – 由於答錄機類型眾多導致誤報，系統留下語音信箱訊息的比例高達 50% 到 60%。此外，AMD 有可能因略為延遲了即時通話而惹惱客戶。
+ **最佳用法** – 在可能有大量答錄機接聽、且不一定每個通話都必須收到語音信箱訊息的那一天撥打電話給消費者。
使用案例 2：AMD 開啟，但不留下自動語音信箱訊息
+ **優點** – 客服人員 95% 的時間都在與即時通話互動，通話時間得以最大化。
+ **缺點** – 無法留下任何語音信箱訊息。導致即時通話延遲而使客戶不悅。
+ **最佳用法** – 在您可能收到大量語音信箱訊息、但不想留下任何語音信箱訊息的那一天撥打電話給消費者。
使用案例 3：AMD 關閉，且客服人員可留下手動語音信箱訊息
+ **優點** – 可留下語音信箱訊息的比例為 100%。
+ **缺點** – 客服人員必須判斷他們接聽的是即時通話還是語音信箱。語音信箱必須以手動方式留下。最為耗時，且可能減少客服人員一天可撥打的通話數。
+ **最佳用法** – 撥打電話給消費者或企業，並留下自訂語音信箱訊息。
使用案例 4：AMD 關閉，且客服人員可留下預先錄製的語音信箱訊息
+ **優點** – 客服人員每次都可留下個人化、100% 預先錄製的語音信箱訊息，並透過「語音信箱投遞」功能避免重複相同的訊息，進而節省大量時間。
+ **缺點** – 客服人員必須判斷他們接聽的是即時通話還是語音信箱。比 AMD 耗時，但比手動留下語音信箱訊息快速。
+ **最佳用法** – 撥打電話給消費者或企業，並留下通用語音信箱訊息。
## 將已排序的客群與對外行銷活動和旅程搭配使用
建立客群時，您可以選擇排序最多 10 個設定檔屬性。外撥行銷活動和旅程在執行期間遵守此排序順序，並依照行銷活動或旅程執行時客群指定的順序處理和撥號設定檔。用於週期性行銷活動或旅程時，每次行銷活動或旅程重複，以及將新設定檔新增至客群時，都會評估排序客群的順序。
當您想要：
+ 透過排序生命週期值或帳戶層等屬性，排定高價值客戶的優先順序。
+ 先在預約日期排序，以聯絡即將預約的客戶。
+ 以特定順序處理時間敏感的通訊。
**注意**
客群排序順序僅適用於旅程中的語音行銷活動和語音活動。其他通訊管道會以未排序的順序處理設定檔。
已排序的區段會分割為 100 個批次。每個批次都會根據指定的排序順序進行處理。這會導致執行順序在定義的區段順序的 1% 以內。
初始撥號嘗試優先於行銷活動中定義的任何重試。在旅程中，較舊的傳送通訊區塊會優先於較晚的通訊區塊。
如需建立和排序客群的詳細資訊，請參閱[在 Amazon Connect 中建置客戶客群](customer-segments-building-segments.md)。