---
title: "Contact, danh tính theo kênh, hồ sơ liên kết"
description: "Một người thật có thể nằm trong nhiều bản ghi liên hệ của CloudFly Helpdesk. Danh tính theo kênh, hồ sơ liên kết và tính bắc cầu của liên kết."
updated: "2026-08-28"
audience: [agent, administrator]
source: "https://helpdesk-docs.svr1.feedapp.click/khai-niem/contact-va-ho-so-lien-ket"
---

Một người thật thường nằm trong nhiều bản ghi của hệ thống, mỗi kênh một bản
ghi. Hợp nhất chúng lại là việc của con người, không phải của thuật toán, và
tài liệu này giải thích mô hình đằng sau thao tác đó.

Đây cũng là chỗ nhạy cảm nhất trong hệ thống: một liên kết đặt nhầm làm lịch sử
của người này hiện ra dưới tên người kia.

## Liên hệ là hồ sơ của một người bên ngoài [#liên-hệ-là-hồ-sơ-của-một-người-bên-ngoài]

**Liên hệ** giữ tên, email, số điện thoại chuẩn hoá, các thuộc tính tuỳ ý, nhãn
và trạng thái chặn. Nó là thứ hội thoại và phiếu hỗ trợ cùng trỏ tới, nên hai
loại bản ghi công việc gặp nhau ở đây.

Một liên hệ được tạo ra khi có tin đầu tiên từ một người lạ, hoặc do nhân viên
tự tạo. Nó không mang khái niệm "kênh": kênh nằm ở lớp danh tính bên dưới.

## Danh tính theo kênh [#danh-tính-theo-kênh]

Mỗi kênh nhận ra khách bằng một mã của riêng nó. Hệ thống lưu các mã đó thành
danh tính, mỗi danh tính gồm tên nhà cung cấp và mã bên ngoài:

| Kênh             | Mã được lưu                     | Ai xác nhận mã này                                    |
| ---------------- | ------------------------------- | ----------------------------------------------------- |
| Facebook         | PSID của Page                   | Meta                                                  |
| Zalo             | Zalo UID                        | Zalo                                                  |
| Telegram         | Mã cuộc trò chuyện              | Telegram                                              |
| Tiện ích website | Mã do trình duyệt khách sinh ra | Không ai — đó là giá trị trình duyệt tự giữ và tự gửi |

Dòng cuối đáng để phân biệt với ba dòng trên. Một PSID do Meta khẳng định, còn
mã widget sống trong trình duyệt của khách. Xoá dữ liệu trình duyệt là có mã
mới, và một người đổi máy sẽ thành một liên hệ mới.

Một cặp nhà cung cấp và mã bên ngoài thuộc về đúng một liên hệ. Tin nhắn đến
không tự chuyển danh tính sang liên hệ khác, vì một danh tính đổi chủ nghĩa là
tài khoản của một người đổi chủ.

## Vì sao một người lại có nhiều bản ghi [#vì-sao-một-người-lại-có-nhiều-bản-ghi]

Giữa một PSID Facebook và một Zalo UID không có gì nối chúng lại. Hệ thống gộp
được khi hai bản ghi trùng email hoặc trùng số điện thoại; ngoài trường hợp đó,
bằng chứng phải đến từ một người nói ra.

Vì vậy khách nhắn qua Facebook hôm nay và qua widget tuần sau thường tạo ra hai
liên hệ, mỗi liên hệ mang lịch sử của riêng nó.

## Hồ sơ liên kết là một phán đoán, và nó được ghi lại [#hồ-sơ-liên-kết-là-một-phán-đoán-và-nó-được-ghi-lại]

Trong ngăn thông tin liên hệ, khối **Hồ sơ liên kết** là nơi bạn tuyên bố "hai
bản ghi này là một người". Nút **Liên kết hồ sơ** mở danh sách gợi ý dưới tiêu
đề **Có thể là cùng một người**, kèm lý do: **trùng số điện thoại**, **trùng
email** hoặc **trùng tên**.

Ba lý do đó không ngang nhau. Trùng số điện thoại gần như là bằng chứng, trùng
tên chỉ là một lời nhắc bạn nhìn kỹ, và console xếp theo đúng thứ tự đó. Không
gợi ý nào tự tạo liên kết.

Liên kết đảo ngược được bằng **Gỡ liên kết**, với câu xác nhận **Không phải
cùng một người?**. Cả hành động liên kết lẫn gỡ liên kết đều để lại một dòng
trong lịch sử của liên hệ, có tên người đã làm.

## Liên kết có tính bắc cầu [#liên-kết-có-tính-bắc-cầu]

Liên kết không phải một cặp, nó là một nhóm. Nối A với B rồi nối B với C thì A
nhìn thấy luôn C, vì cả ba cùng thuộc một người, và hai nhóm được nối thì hợp
nhất chứ không đứt đoạn.

Gỡ liên kết lấy đúng một bản ghi ra khỏi nhóm, để nguyên phần còn lại. Nhóm còn
lại đúng một thành viên sẽ tự tan, vì một bản ghi đứng một mình không nói lên
điều gì.

> **Cảnh báo:** Nối nhầm hai người là để lịch sử của một khách hiện ra dưới tên khách khác
> trên màn hình nhân viên. Trước khi nối, đối chiếu một bằng chứng thật: số điện
> thoại, email, hoặc câu chính khách xác nhận trong hội thoại.

## Khách không nhìn thấy phần mở rộng này [#khách-không-nhìn-thấy-phần-mở-rộng-này]

Việc mở rộng lịch sử theo nhóm liên kết là chuyện của màn hình nhân viên. Danh
sách **Hội thoại khác** trong ngăn liên hệ trải khắp mọi bản ghi đã nối. Mỗi
dòng in kèm tên và email của bản ghi giữ nó, để bạn biết dòng nào thuộc hồ sơ
nào.

Các đường đọc dành cho khách thì không mở rộng như vậy. Khung chat của khách và
cổng khách hàng vẫn cắt theo hộp thư và theo đúng liên hệ của phiên đó. Một
liên kết sai vì thế không đẩy lịch sử người này vào cửa sổ chat của người kia.

## Insight — chỗ ghi thứ không API nào đọc được [#insight--chỗ-ghi-thứ-không-api-nào-đọc-được]

Khối **Insight** trong cùng ngăn giữ những gì đồng nghiệp gõ tay: nhóm Zalo,
hồ sơ CRM, một số điện thoại phụ. Mỗi mục có nhãn, kiểu giá trị và tên người đã
ghi, nên một mục cũ luôn có người để hỏi lại.

Insight khác hồ sơ liên kết. Nó là ghi chú về nơi khác mà doanh nghiệp chạm tới
khách, chứ không tuyên bố hai bản ghi là một người.

## Đọc tiếp [#đọc-tiếp]

* [Bảng thuật ngữ](/khai-niem/thuat-ngu)
* [Khi nào dùng hội thoại, khi nào dùng ticket](/khai-niem/hoi-thoai-vs-ticket)
* [Làm việc với hộp thư](/hop-thu)