Khoảng ngày mười hàng tháng, nhóm kế toán lại gửi đi cùng một yêu cầu. Họ cần năm tệp từ mỗi khách hàng: sao kê ngân hàng, kho lưu trữ biên lai, báo cáo lương, tóm tắt doanh số và tài liệu kiểm kê. Mẫu email rất thân thiện, chính xác và đã được kiểm chứng. Nó chào khách hàng bằng tên, liệt kê các tệp cần thiết và đưa ra thời hạn rõ ràng. Ở lần gửi đầu tiên, mọi thứ đều suôn sẻ. Khách hàng thấy một danh sách gọn gàng và phản hồi lại.

Rắc rối bắt đầu từ email thứ hai.

Hãy tưởng tượng một khách hàng gửi bốn tệp. Tệp sao kê ngân hàng thứ năm không bao giờ đến. Kho lưu trữ biên lai có gửi đến, nhưng lại thuộc về tháng sai, vì vậy nhóm đã từ chối nó. Báo cáo lương thực tế đã được gửi qua Slack từ ba ngày trước và ai đó đã lưu trữ nó rồi. Tài liệu kiểm kê hoàn toàn không áp dụng cho khách hàng này, một chi tiết mà bạn chỉ phát hiện ra sau khi tin nhắn đầu tiên đã được gửi đi. Nếu bạn gửi lại mẫu email gốc, bạn lại yêu cầu năm tệp một lần nữa. Bốn trong số các yêu cầu đó giờ đây trở nên vô nghĩa. Một yêu cầu khác lại gây hiểu lầm. Cách dùng từ thì không vấn đề gì. Vấn đề là email đơn giản là không có "trí nhớ".

Một mẫu email xử lý tốt các tên, ngày tháng và hướng dẫn. Đối với một yêu cầu nhỏ, mang tính nhất thời, điều đó thường là đủ. Một người gửi thư, khách hàng trả lời, và chính người đó hoàn thành nhiệm vụ. Lịch sử giao dịch nằm gọn trong một bộ não và một hộp thư đến.

Các vấn đề bắt đầu nảy sinh khi tin nhắn tiếp theo phụ thuộc vào các sự kiện xảy ra sau email đầu tiên. Mẫu email vẫn hiển thị danh sách ban đầu. Nó không biết rằng một bản sao kê ngân hàng đã đến vào ngày hôm qua. Nó không biết rằng một báo cáo lương đã bị từ chối. Dữ liệu đó nằm trong hộp thư đến, có thể là ở nhiều hộp thư khác nhau, và ứng dụng tạo lời nhắc không có cách nào để đọc được chúng.

Khi trạng thái "Mở" là chưa đủ

Nếu bạn theo dõi toàn bộ yêu cầu dưới một trạng thái duy nhất như "mở" (open), bạn sẽ mất đi những chi tiết quan trọng. Các hạng mục di chuyển độc lập với nhau. Mỗi hạng mục cần có trạng thái riêng để lần liên lạc tiếp theo có thể chính xác:

  • Sao kê ngân hàng: Còn thiếu. Khách hàng chưa gửi.
  • Kho lưu trữ biên lai: Đã tải lên nhưng chưa được xem xét. Nó đang nằm trong một thư mục chờ kiểm tra nội bộ.
  • Báo cáo lương: Đã bị từ chối. Khách hàng đã gửi thứ gì đó, nhưng sai định dạng hoặc sai kỳ lương.
  • Báo cáo doanh số: Đã nhận qua kênh khác. Nó được gửi qua Slack, qua điện thoại hoặc bản sao gửi qua bưu điện, và nhóm của bạn đã ghi nhận nó.
  • Tài liệu kiểm kê: Không áp dụng. Khách hàng này không cần cung cấp tài liệu này, và hệ thống nên ngừng yêu cầu.

Nếu không có sự phân tách này, lời nhắc của bạn sẽ trở nên "mù quáng". Nó đối xử với một tệp còn thiếu và một tệp bị từ chối theo cùng một cách. Nó đối xử với một tệp đã có trong tay như thể nó chưa bao giờ được gửi đến. Điều đó làm lãng phí thời gian của khách hàng và làm xói mòn lòng tin. Sau hai hoặc ba lời nhắc không liên quan, khách hàng sẽ chỉ đọc lướt qua. Họ sẽ cho rằng hệ thống của bạn đang gặp lỗi.

Chỉ xây dựng những gì bạn cần

Đừng xây dựng một bộ máy quy tắc khổng lồ ngay từ đầu. Bạn không cần một hệ thống tự động hóa quy trình làm việc với hai mươi nhánh điều kiện ngay trong ngày đầu tiên. Hãy bắt đầu bằng việc theo dõi vừa đủ dữ liệu để trả lời một câu hỏi: Điều gì vẫn cần khách hàng thực hiện?

Mỗi hạng mục được yêu cầu cần có một kết quả bền vững. Điều đó có nghĩa là một bản ghi tồn tại bên ngoài luồng email, ở một nơi mà ứng dụng có thể đọc được khi nó soạn tin nhắn tiếp theo. Bản ghi không cần phải phức tạp. Nó có thể đơn giản như một bảng có cấu trúc chứa tên hạng mục, trạng thái hiện tại, dấu thời gian và một ghi chú ngắn. Điều quan trọng là dữ liệu phải tồn tại lâu hơn một hộp thư đến.

Điều này thay đổi vai trò của email. Mẫu email vẫn kiểm soát tông giọng và cấu trúc. Lời chào vẫn ấm áp, hướng dẫn vẫn rõ ràng. Nhưng danh sách tài liệu phải được lấy từ dữ liệu yêu cầu. Lời nhắc trở thành một truy vấn. Bạn lọc danh sách để chỉ hiển thị các hạng mục cần khách hàng thực hiện. Bạn loại bỏ các hạng mục đang chờ xem xét nội bộ. Bạn loại bỏ các hạng mục đã được chấp nhận.

Nếu một tệp tải lên bị từ chối, lời nhắc nên nói rõ điều đó và giải thích lý do tại sao. Nó không nên âm thầm đưa tài liệu đó trở lại danh sách chung như thể khách hàng chỉ đơn giản là quên gửi. Khách hàng biết họ đã tải lên thứ gì đó; việc giả vờ như không có gì sẽ khiến bạn trông có vẻ thiếu tổ chức.

Bài kiểm tra bàn giao

Có một cách đơn giản để biết liệu bạn có cần mô hình dữ liệu bổ sung này hay không. Hãy hỏi:

Liệu một thành viên khác trong nhóm có thể tiếp quản yêu cầu này mà không cần đọc toàn bộ luồng email hay không?

Đối với một tệp đơn lẻ, câu trả lời không quan trọng. Đối với các yêu cầu hàng tháng lặp đi lặp lại với nhiều yếu tố thay đổi, nó lại cực kỳ quan trọng. Nếu người liên hệ chính đang đi nghỉ, liệu một đồng nghiệp có thể biết ngay trong vài giây những gì còn thiếu không? Liệu một quản lý có thể biết khách hàng đã hoàn tất mọi việc chưa mà không cần phải mở mười email và ba thư mục dùng chung? Nếu nơi duy nhất ghi lại một sự từ chối là tin nhắn thứ tư trong một luồng email, bị vùi lấp dưới các chữ ký và các thư chuyển tiếp, thì hệ thống của bạn đang buộc con người phải làm công việc mà lẽ ra một cơ sở dữ liệu nên làm.

Các mẫu (Templates) giúp cải thiện thông điệp. Một yêu cầu được theo dõi giúp lưu giữ lịch sử. Một cái xử lý cách bạn nói. Cái còn lại xử lý những gì bạn biết.

Truy vấn, không phải Kịch bản

Một khi bạn đã có các trạng thái theo từng mục, việc tạo email sẽ chuyển từ viết kịch bản sang truy vấn. Trước đây, bạn viết một đoạn văn và hy vọng nó vẫn chính xác. Giờ đây, bạn hỏi dữ liệu của mình: mục nào trong số này vẫn cần khách hàng xử lý? Bạn soạn lời nhắc dựa trên danh sách đã được lọc đó. Nếu không có gì cần xử lý, bạn sẽ không gửi lời nhắc. Nếu có hai mục cần xử lý và một mục bị từ chối vì một lý do cụ thể, email sẽ tự động được xây dựng dựa trên những sự thật đó.

Điều này