Tình huống minh họa: Thứ Sáu 16:30, inquiry đi Chicago từ khách mới. Nó vào hộp chung và nằm đó — thứ Hai 9:00 mới có reply. Khách đã ký với forwarder khác từ tối thứ Sáu. Vụ này không phải cá biệt: ba tháng sau đếm lại, 6/17 inquiry không trả lời trong 8 tiếng — và công ty không hề biết con số đó vì không ai đếm.
Trả lời ngắn: Booking mất vì chậm không phải vì sales thiếu nỗ lực — vì inquiry không có luồng và SLA: (1) inquiry vào một nơi — không rơi vào hộp chung không chủ; (2) mỗi inquiry gán người phụ trách trong vài phút, có đồng hồ; (3) SLA trả lời theo giờ đo được — ai nhanh ai chậm lộ rõ. Kết quả: 80% quote ra trong 60 phút, booking không còn mất vì reply trễ.
Bài viết này dành cho ai?
Dành cho giám đốc kinh doanh forwarder — nơi inquiry đến 3 địa chỉ email chung, không ai biết mình đang giữ bao nhiêu inquiry chưa trả lời, và booking mất về tay đối thủ không phải vì giá mà vì chậm.
Điều gì đang xảy ra?
- Inquiry đến 3 địa chỉ email chung — không gán ai.
- Không biết đang giữ bao nhiêu inquiry chưa trả lời.
- Reply sau 4–24 tiếng tùy người online hay không.
- Không có con số nào về tốc độ trả lời từng sales.
- Inquiry rơi lúc cuối giờ — sáng mai mới ai thấy.
- Booking mất về đối thủ mà không ai biết vì sao mất.
Điều doanh nghiệp muốn đạt được
Chức năng: một luồng inquiry tập trung, gán người tự động, đồng hồ SLA theo giờ. Quản trị: tỷ lệ reply đúng SLA xem theo tuần — theo sales. Tổ chức: hết hộp email chung "ai thấy thì trả lời".
Điều gì đang cản trở?
| Lớp cản trở | Biểu hiện | Hệ quả |
|---|---|---|
| Dữ liệu | Inquiry rải 3 hộp chung không gán | Không đếm được đang nợ reply bao nhiêu |
| Quy trình | Không có SLA trả lời theo giờ | Nhanh chậm tùy hứng từng người |
| Kiểm soát | Không đo tốc độ từng sales | Người chậm không lộ — không cải thiện |
| Tổ chức | Cuối giờ không ai nhận trách nhiệm | Inquiry thứ Sáu sáng thứ Hai mới thấy |
| Công cụ | Không cảnh báo inquiry quá giờ | Mất booking xong mới hay có inquiry |
Điểm nhìn cốt lõi: Forwarder không mất booking vì giá cao — mất vì reply chậm: khách gửi inquiry cho 4–5 forwarder cùng lúc, người trả lời trước với đủ thông tin thường thắng trước khi soánh giá bắt đầu. Trong cuộc đua đó, hộp email chung là tự sát có tổ chức: mỗi inquiry không gán người là một con bài rơi — 17 inquiry ba tháng, 6 rơi, công ty không con số nào. Đo tốc độ trả lời theo giờ là việc phải làm trước cả khi bàn giá.
Tác động tới doanh nghiệp
| Chiều tác động | Điều gì xảy ra khi inquiry không có SLA |
|---|---|
| Cost | Chi phí marketing tạo inquiry — rơi tại hộp chung |
| Revenue | Booking mất về đối thủ vì reply trễ — không đo được |
| Progress | Pipeline không đếm được inquiry sống — dự báo lệch |
| Risk | Inquiry ẩn lúc cuối giờ — mất âm thầm mỗi tuần |
| Compliance | Inquiry không lưu trữ tập trung — khó truy vấn lại |
Nguyên nhân gốc
Inquiry rải 3 hộp email chung ↓ Không gán người — không có đồng hồ ↓ Không SLA trả lời theo giờ ↓ Không đo tốc độ từng sales ↓ Không cảnh báo inquiry quá giờ ↓ Kết quả: booking mất vì reply trễ — không ai đếm
Framework inquiry SLA 5 bước
MỘT LUỒNG — inquiry vào một nơi duy nhất ↓ GÁN NGAY — người phụ trách trong vài phút ↓ ĐỒNG HỒ SLA — reply trong giờ, không trong ngày ↓ ĐO THEO NGƯỜI — ai nhanh ai chậm lộ rõ ↓ DANH SÁCH NỢ — chưa reply hiện diện trước mắt
Inquiry tập trung một luồng, gán người trong phút, đồng hồ SLA theo giờ và danh sách nợ reply luôn mở — booking không còn mất vì chậm trả lời.
Khám phá EcoLog →Quy trình inquiry SLA (To-Be)
| Bước | Người phụ trách | Đầu vào | Điểm kiểm soát |
|---|---|---|---|
| Thu inquiry về một luồng | Quản trị | Form + email tự dẫn | Không hộp chung nào còn nhận inquiry |
| Gán người phụ trách | Trưởng nhóm sales | Luồng inquiry | Mỗi inquiry có chủ trong vài phút |
| Phân loại theo loại hàng | Sales được gán | Nội dung inquiry | Loại khó chuyển đúng người ngay |
| Đồng hồ SLA theo giờ | Hệ thống | Inquiry + giờ đến | Quá 60 phút — cảnh báo lên trưởng nhóm |
| Đo tốc độ từng sales | Trưởng nhóm sales | Dữ liệu reply | Báo cáo tuần ai nhanh ai chậm |
| Xét booking thắng/mất | Sales manager | Kết quả inquiry | Mất vì giá hay vì chậm — tách rõ |
Ví dụ minh họa — số liệu giả định
Ví dụ minh họa — số liệu giả định, không phải thống kê.
Forwarder 12 sales, ~60 inquiry/tháng — hai kiểu quản luồng.
| Chỉ số | 3 hộp chung | Một luồng + SLA giờ |
|---|---|---|
| Reply trung bình | 9 tiếng — cuối tuần 40+ tiếng | 55 phút |
| Inquiry reply trong 60 phút | ~30% | 80% |
| Inquiry không ai gán | Xảy ra hằng tuần | 0 — gán tự động |
| Booking giữ từ inquiry mới | Không đo được | 37% — đo theo nguồn |
| Sales chậm nhất lộ rõ | Không ai biết | Báo cáo tuần theo người |
| Inquiry cuối giờ thứ Sáu | Nằm tới sáng thứ Hai | Gán ngay — reply tối đó |
Cách dùng: hỏi hôm nay công ty đang nợ reply bao nhiêu inquiry, lâu nhất bao nhiêu tiếng — câu trả lời cần mở 3 hộp email đếm tay nghĩa là danh sách nợ không tồn tại.
Bài kiểm 15 phút: chọn 10 inquiry gửi gần nhất, đếm thời gian từ lúc khách gửi tới khi nhận phản hồi đầu tiên có nội dung. Quá nửa vượt 4 tiếng thì vấn đề không phải cá nhân — là luồng; và phép đo này lặp mỗi tuần cùng một cách đo để thấy xu hướng sau khi đổi luồng, thay vì cảm giác "hình như nhanh hơn".
Tuần đầu chỉ hai việc: dồn inquiry về một form (hoặc một địa chỉ duy nhất có thông báo) và quy tắc gán người trong 15 phút giờ hành chính. Tuần thứ ba thêm đồng hồ SLA và báo cáo tuần theo sales. Chỗ hay vấp: sales lo bị "đo" — nhưng số liệu đầu tiên thường cho thấy vấn đề nằm ở luồng chứ không ở người; sửa luồng trước, số cá nhân mới có ý nghĩa cải thiện.
Chỉ số báo hiệu luồng hỏng trở lại: số inquiry "không rõ ai giữ" khác 0 dù chỉ một bản ghi trong tuần. Luồng inquiry là hạ tầng của pipeline kinh doanh — để một inquiry không chủ lọt lại là cảnh báo sớm hơn mọi KPI khác.
Giải pháp hỗ trợ ở đâu?
| Yêu cầu | Năng lực | Mức đáp ứng |
|---|---|---|
| Một luồng inquiry | Webform + email-to-lead tự tạo | Tiêu chuẩn |
| Gán người tự động | Phân loại theo rule — gán round-robin | Cấu hình |
| Đồng hồ SLA theo giờ | SLA theo stages + cảnh báo quá giờ | Tiêu chuẩn + cấu hình |
| Đo tốc độ từng người | Báo cáo theo sales — tuần | Tiêu chuẩn |
| Danh sách nợ reply mở | Pipeline view theo stages | Tiêu chuẩn |
AI / Automation hỗ trợ ở đâu?
AI bổ trợ ở ba việc: phân loại inquiry theo loại hàng/tuyến để gán đúng người ngay; soạn nháp reply với rate đang hiệu lực để sales duyệt trong phút; tóm tắt nội dung email dài thành yêu cầu rõ trước khi trả lời. AI không tự gửi quote — sales duyệt nội dung và giá trước khi rời công ty.
KPI inquiry SLA cần theo dõi
| KPI | Công thức | Tần suất | Chủ sở hữu | Hành động khi lệch |
|---|---|---|---|---|
| Reply trong 60 phút | Số đúng SLA ÷ tổng inquiry | Tuần | Sales manager | <80% — xem luồng trước, người sau |
| Inquiry có chủ trong 15 phút | Số gán đúng ÷ tổng | Tuần | Trưởng nhóm | Rơi — rule gán hỏng |
| Inquiry quá 1 ngày chưa reply | Số vụ | Tuần | Sales manager | Có — gán người xử ngay |
| Booking giữ từ inquiry | Thắng ÷ tổng inquiry mới | Tháng | Giám đốc KD | Giảm — tách lý do giá/chậm |
| Tốc độ từng sales | Trung bình reply theo người | Tuần | Sales manager | Người chậm — đào tạo tải |
Câu hỏi thường gặp
SLA 60 phút có hợp lý khi inquiry phức tạp?
SLA không phải là quote đầy đủ trong 60 phút — là phản hồi có nội dung trong 60 phút: xác nhận đã nhận, nêu cần bổ sung gì, hẹn thời điểm quote đầy đủ. Khách không cần giá chính xác ngay — cần biết ai đang giữ yêu cầu của mình. Quote đầy đủ có thể 4–8 tiếng với hàng đặc biệt, nhưng im lặng 4 tiếng là mất quyền vào cuộc.
Sales đang bận deal lớn — inquiry nhỏ ai lo?
Chính vì bận mới cần gán tự động: inquiry nhỏ về người rảnh theo rule phân loại, không rơi vì người giỏi bận. Nếu tất cả cùng bận thì trưởng nhóm thấy cảnh báo quá giờ trên dashboard — quyết định chuyển hoặc nhận thêm là của quản lý, không còn là "hộp chung không ai thấy".
Inquiry qua Zalo/điện thoại có vào luồng không?
Có — quy tắc là mọi inquiry tạo một bản ghi trong luồng, nguồn ghi rõ (form, email, Zalo, điện thoại). Ghi chép 30 giây khi nhận cuộc gọi cũng đủ để inquiry không rơi. Điều cần tránh là nguồn ngoài luồng không lưu — mất booking rồi không biết từng nhận inquiry.
Đo tốc độ từng sales có gây áp lực sai?
Số đầu tiên thường chứng minh vấn đề ở luồng chứ không ở người: inquiry rơi hộp chung, không gán ai thì ai cũng chậm. Sửa luồng trước, sau đó số cá nhân mới ý nghĩa — dùng để cải thiện, không để trừng phạt. Sales nhanh nhất thường ủng hộ việc đo: họ thắng booking nhiều nhất và muốn công ty biết reply chậm đang tốn bao nhiêu.
Khách gửi inquiry cho nhiều forwarder — đo sao đúng?
Đo phần mình kiểm soát được: tốc độ reply và tỷ lệ inquiry thành quote. Booking thắng/mất là tổng hòa giá — dịch vụ — quan hệ; nhưng trong nhóm thua, phần thua vì chậm reply là phần sửa được ngay và rẻ nhất. Tách được "thua vì giá" khỏi "thua vì chậm" đã là nâng cấp lớn so với không đo gì.
Bài học một câu?
Forwarder không mất booking vì giá — mất vì im lặng: một luồng inquiry gán người trong phút, đồng hồ SLA theo giờ, danh sách nợ reply luôn mở — khách được trả lời trước khi nghĩ đến forwarder khác.
Checklist: doanh nghiệp của bạn có vấn đề này không?
Đọc kết quả: 0–2 ô = luồng inquiry đã chạy SLA; 3–5 ô = cần dồn một luồng + gán người; 6–8 ô = mỗi inquiry đang là con bài rơi — và khách đã gửi bản sao cho đối thủ trước khi công ty kịp mở email.
Kết luận
Booking của forwarder quyết trong vài giờ đầu — trước khi soánh giá bắt đầu: inquiry rơi hộp chung không chủ là mất quyền vào cuộc. Một luồng, gán trong phút, đồng hồ SLA theo giờ, danh sách nợ reply mở — 80% quote trong 60 phút và khách được trả lời trước khi nghĩ đến forwarder khác.