OMICard系統提供叢集運算（Cluster）及備援（Standby）的功能

OMICard包含AP、Sender、Web、File Server、DB等子模組系統

OMICard可依需求等級做高可用性(High Availability, HA)、災難復原(Disaster Recovery, DR)之在地備援或異地備援等的配置，確保營運可持續性(Business Continuity, BC)。

在發信過程，所有郵件系統都會經過『產信』再『發信』這兩個步驟，OMICard系統在產信前會依系統或是使用者的設定先行排除無效名單、重複名單、取消訂閱、黑名單、白名單、已知退信、關鍵字過濾等等名單剔除流程再產信，產完信後即刻送至發信機開始發送（開始SMTP Session）。

一封郵件在發信最終結果只有兩種結果：成功與失敗，但是可能會經過嘗試發信數次後（1 ~ N次或是發送時間截止）才會決定最終結果，最終發不出去的郵件會被當退信（Hard bounce）處理，但是即使發信成功後，接收方郵件系統仍然可能會依他們的設定條件後續再退信（Soft bounce）。

退信依過程可分為Hard Bounce （發不出去）及Soft Bounce（發成功再被退回），但是退信原因依據多年經驗可分為近40種（請參閱列表），目前是業界公認最詳細最準確的退信分析，由於可以準確判定退信原因，系統才知道如何準確因應發信，這也是OMICARD發信成功率及發信效率高的原因。

All in One單機型：適用於較小發送量之系統建構環境；單主機多發送機型：適用單次發送量超過10萬筆以上之系統建置環境；叢集架構：通常是在單一OMICard主機無法在所要求的時間內及時處理完大家郵件之打包作業時會採用；離線式架構：不管是單機或多機模式，皆可設計離線存取之建構模式，將代理主機建置於網路較為穩定之IDC或是較為穩定之網路環境上。

具有DMZ架構之建構模式：通常運用於需要較高安全性的資料隱密性的系統架構，僅將WEB及SMTP SERVER 建置於DMZ區，其他如OMICard主機、DB主機皆放置於內部網路，對外僅能看到DMZ區之機器，就算日後發生駭客入侵之情況，也因為資料庫不在DMZ區內，且中間亦無任何可以直接連線之資料取出方法，所以也不會發生任何資料外洩情況，為目前安全性最高的建置方法之一。

此模式為最高安全性之系統建置方法，對外部而言，只會看到一組代理網頁主機及代理郵件發送機，而代理主機與系統主機之存取模式是採取被動式的存取方式，代理主機可以與主機群不用保持ONLINE連線之模式，所以主機群可以建構於內部網路內，只要能連線上網，並能存取的到代理主機即可運作，而資料的回傳作業，是在主機設定的排程內，由主機以單向取回資料的方式向代理主機取回尚未處理的資料並寫入資料庫中後進行分析。

1.總寄送報表：紀錄郵件的詳細發送情形，如：名單總數、有效名單數、系統送出郵件數…等，以及郵件內容的連結數、檔案數與發送時間。

2.傳送報表：紀錄郵件成功送達客戶信箱的數量及目標客戶或轉寄郵件的詳細情形，如：退信率、成功發送率、轉寄率、平均每人轉寄郵件數…等。

3.開啟報表：紀錄開啟郵件的數量及閱覽的次數，包括開啟率與平均展信次數。

4.點選報表：紀錄點閱郵件頁面上連結選項的郵件數與點選數，包括點選率與平均點選次數。

5.退信報表：記錄此次寄送任務的退信情形，如退信比例和退信原因之排名。

1.簡訊總寄送報表：紀錄簡訊的詳細發送情形，如：簡訊總數、有效手機號碼、無效手機號碼、簡訊發送狀態、發送時間等。

2.簡訊傳送報表：紀錄簡訊成功送達客戶的數量詳細情形，如：系統針對目標客戶發送出的簡訊總數、已收到數量、未收到數量、已發送至電信單位但狀態未知的數量…等。

3.簡訊發送失敗下載報表：記載發送失敗的簡訊。

4.簡訊已送至電信單位的細節：簡訊已送至電信單位的細節。

5.記載客戶已收到簡訊的細節：記載客戶已收到簡訊的細節。

6.記載客戶未收到簡訊的細節：記載客戶未收到簡訊的細節。

7.無效簡訊下載報表：記載無效的簡訊與遞交時間。