ทุกๆ เดือนในช่วงประมาณวันที่สิบ ทีมบัญชีจะส่งคำขอแบบเดิมออกไป พวกเขาต้องการไฟล์ห้าอย่างจากลูกค้าแต่ละราย ได้แก่ รายการเดินบัญชีธนาคาร (bank statement), ไฟล์รวมใบเสร็จ (receipt archive), รายงานเงินเดือน (payroll report), สรุปยอดขาย (sales summary) และเอกสารสินค้าคงคลัง (inventory document) เทมเพลตที่ใช้นั้นดูเป็นกันเอง แม่นยำ และผ่านการทดสอบมาแล้ว มันทักทายลูกค้าด้วยชื่อ ระบุรายการไฟล์ที่ต้องการ และแจ้งกำหนดส่งที่ชัดเจน ในการส่งครั้งแรก ทุกอย่างดูราบรื่น ลูกค้าเห็นรายการที่จัดระเบียบมาอย่างดีและตอบกลับมา

ปัญหาเริ่มขึ้นเมื่อถึงอีเมลฉบับที่สอง

ลองจินตนาการว่าลูกค้าคนหนึ่งส่งไฟล์มาสี่อย่าง แต่รายการเดินบัญชีธนาคารฉบับที่ห้าไม่เคยมาถึง ไฟล์รวมใบเสร็จถูกส่งมาจริง แต่เป็นของเดือนที่ผิด ทีมงานจึงต้องปฏิเสธไป รายงานเงินเดือนจริงๆ แล้วถูกส่งมาทาง Slack เมื่อสามวันก่อน และมีคนบันทึกข้อมูลไปแล้ว ส่วนเอกสารสินค้าคงคลังก็ไม่ได้เกี่ยวข้องกับลูกค้ารายนี้เลย ซึ่งเป็นรายละเอียดที่คุณเพิ่งมารู้หลังจากส่งข้อความแรกออกไปแล้ว หากคุณส่งเทมเพลตเดิมซ้ำ คุณก็กำลังขอไฟล์ทั้งห้าอย่างอีกครั้ง ซึ่งสี่อย่างในนั้นกลายเป็นเรื่องไร้ประโยชน์ และอีกหนึ่งอย่างก็เป็นการให้ข้อมูลที่ผิดพลาด ทั้งที่ถ้อยคำในอีเมลนั้นใช้ได้ดี แต่ปัญหาคืออีเมลไม่มี "ความจำ"

เทมเพลตอีเมลจัดการเรื่องชื่อ วันที่ และคำแนะนำได้ดี สำหรับการขอข้อมูลเล็กๆ น้อยๆ เพียงครั้งเดียว นั่นมักจะเพียงพอแล้ว เมื่อคนหนึ่งส่งอีเมล ลูกค้าตอบกลับ และคนเดิมก็จัดการงานนั้นจนเสร็จ ประวัติการติดต่อทั้งหมดจะถูกเก็บไว้ในสมองของคนคนเดียวและในกล่องจดหมายเพียงกล่องเดียว

ปัญหาจะเริ่มขึ้นเมื่อข้อความถัดไปต้องขึ้นอยู่กับเหตุการณ์ที่เกิดขึ้นหลังจากอีเมลฉบับแรก เทมเพลตยังคงแสดงรายการเดิม มันไม่รู้ว่ารายการเดินบัญชีถูกส่งมาเมื่อวานนี้ และไม่รู้ว่ารายงานเงินเดือนถูกปฏิเสธไปแล้ว ข้อมูลเหล่านั้นอยู่ในกล่องจดหมาย ซึ่งอาจจะมีหลายกล่อง และแอปพลิเคชันที่สร้างข้อความแจ้งเตือนก็ไม่มีวิธีที่จะเข้าไปอ่านข้อมูลนั้นได้

เมื่อสถานะ "Open" นั้นไม่เพียงพอ

หากคุณติดตามคำขอทั้งหมดด้วยสถานะเดียว เช่น "open" คุณจะสูญเสียรายละเอียดที่สำคัญไป รายการแต่ละอย่างมีการเคลื่อนไหวที่เป็นอิสระต่อกัน แต่ละรายการจึงต้องการสถานะของตัวเอง เพื่อให้การสื่อสารครั้งต่อไปมีความแม่นยำ:

  • Bank statement: สูญหาย ลูกค้ายังไม่ได้ส่งมา
  • Receipt archive: อัปโหลดแล้วแต่ยังไม่ได้ตรวจสอบ กำลังรอการตรวจสอบภายในอยู่ในโฟลเดอร์
  • Payroll report: ถูกปฏิเสธ ลูกค้าส่งมาแล้ว แต่ผิดรูปแบบหรือผิดงวดการจ่ายเงิน
  • Sales report: ได้รับผ่านช่องทางอื่นแล้ว เช่น ผ่าน Slack, การโทรศัพท์ หรือเอกสารทางไปรษณีย์ และทีมของคุณได้บันทึกข้อมูลไปแล้ว
  • Inventory document: ไม่เกี่ยวข้อง ลูกค้ารายนี้ไม่จำเป็นต้องส่งเอกสารนี้ และระบบควรหยุดถามถึงมัน

หากไม่มีการแยกแยะเช่นนี้ ข้อความแจ้งเตือนของคุณก็จะ "ตาบอด" มันปฏิบัติกับไฟล์ที่หายไปและไฟล์ที่ถูกปฏิเสธเหมือนกัน และปฏิบัติกับไฟล์ที่ได้รับมาแล้วราวกับว่ามันไม่เคยส่งมาเลย สิ่งนี้ทำให้ลูกค้าเสียเวลาและทำลายความเชื่อมั่นลงทีละน้อย หลังจากได้รับข้อความแจ้งเตือนที่ไม่เกี่ยวข้องซ้ำๆ สองหรือสามครั้ง ลูกค้าจะเริ่มอ่านผ่านๆ และทึกทักเอาว่าระบบของคุณเสีย

สร้างเฉพาะสิ่งที่คุณจำเป็นต้องใช้เท่านั้น

อย่าเพิ่งสร้างระบบจัดการกฎ (rules engine) ขนาดใหญ่ตั้งแต่แรก คุณไม่จำเป็นต้องมีระบบอัตโนมัติ (workflow automation) ที่มีเงื่อนไขซับซ้อนถึงยี่สิบรูปแบบตั้งแต่วันแรก เริ่มต้นด้วยการติดตามข้อมูลให้เพียงพอที่จะตอบคำถามเดียวคือ: อะไรที่ลูกค้ายังต้องดำเนินการอยู่?

รายการที่ขอไปแต่ละอย่างต้องการผลลัพธ์ที่คงทน (durable result) นั่นหมายถึงการมีบันทึกข้อมูลที่อยู่นอกเธรดอีเมล ในที่ที่แอปพลิเคชันสามารถอ่านได้เมื่อต้องร่างข้อความถัดไป บันทึกนี้ไม่จำเป็นต้องซับซ้อน อาจจะง่ายๆ แค่ตารางที่มีโครงสร้างซึ่งเก็บชื่อรายการ, สถานะปัจจุบัน, เวลา (timestamp) และบันทึกสั้นๆ สิ่งสำคัญคือข้อมูลนั้นต้องอยู่รอดต่อไปได้แม้จะพ้นจากกล่องจดหมายไปแล้ว

สิ่งนี้จะเปลี่ยนบทบาทของอีเมล แม้เทมเพลตจะยังคงควบคุมโทนเสียงและโครงสร้าง คำทักทายยังคงดูเป็นกันเอง และคำแนะนำยังคงชัดเจน แต่รายการเอกสารจะต้องดึงมาจากข้อมูลคำขอ (request data) ข้อความแจ้งเตือนจะกลายเป็นการคิวรี (query) คุณจะกรองรายการเพื่อแสดงเฉพาะสิ่งที่ลูกค้าต้องดำเนินการ และคัดรายการที่กำลังรอการตรวจสอบภายในหรือรายการที่ได้รับการยอมรับแล้วออกไป

หากการอัปโหลดถูกปฏิเสธ ข้อความแจ้งเตือนควรระบุเช่นนั้นและอธิบายเหตุผล ไม่ควรนำเอกสารนั้นกลับไปใส่ในรายการทั่วไปเงียบๆ ราวกับว่าลูกค้าแค่ลืมส่ง ทั้งที่ลูกค้าทราบดีว่าพวกเขาอัปโหลดไปแล้ว การทำเหมือนไม่รู้จะทำให้คุณดูเป็นคนทำงานไม่เป็นระบบ

บททดสอบการส่งต่องาน (The Handoff Test)

มีวิธีง่ายๆ ที่จะรู้ว่าคุณจำเป็นต้องมีโมเดลข้อมูลเพิ่มเติมนี้หรือไม่ โดยการถามว่า:

สมาชิกคนอื่นในทีมสามารถรับช่วงต่อคำขอนี้ได้หรือไม่ โดยไม่ต้องอ่านเธรดอีเมลทั้งหมด?

สำหรับไฟล์เพียงไฟล์เดียว คำตอบนั้นอาจไม่สำคัญ แต่สำหรับคำขอรายเดือนที่เกิดขึ้นซ้ำๆ และมีรายละเอียดซับซ้อนมากมาย มันสำคัญมาก หากผู้ติดต่อหลักลาพักร้อน เพื่อนร่วมงานจะสามารถดูได้ภายในไม่กี่วินาทีหรือไม่ว่ามีอะไรขาดหายไป? ผู้จัดการจะสามารถบอกได้หรือไม่ว่าลูกค้าดำเนินการครบถ้วนแล้วหรือยัง โดยไม่ต้องเปิดอีเมลสิบฉบับและโฟลเดอร์ที่แชร์กันสามแห่ง? หากที่เดียวที่มีการบันทึกการปฏิเสธคือข้อความที่สี่ในเธรด ซึ่งถูกฝังอยู่ใต้ลายเซ็นและการส่งต่อ นั่นหมายความว่าระบบของคุณกำลังบังคับให้มนุษย์ต้องทำงานที่ฐานข้อมูลควรจะเป็นคนทำ

เทมเพลตช่วยปรับปรุงข้อความ การติดตามคำขอช่วยรักษาประวัติ สิ่งหนึ่งจัดการกับวิธีการที่คุณสื่อสาร ส่วนอีกสิ่งหนึ่งจัดการกับสิ่งที่คุณรู้

การคิวรี ไม่ใช่การเขียนสคริปต์

เมื่อคุณมีสถานะในระดับรายการ (item-level states) การสร้างอีเมลจะเปลี่ยนจากการเขียนสคริปต์เป็นการคิวรี เมื่อก่อนคุณเขียนย่อหน้าหนึ่งแล้วหวังว่ามันจะยังถูกต้อง แต่ตอนนี้คุณสามารถถามข้อมูลของคุณได้ว่า: รายการใดบ้างที่ลูกค้ายังต้องดำเนินการ? คุณจะเขียนข้อความแจ้งเตือนโดยอิงจากรายการที่ผ่านการกรองนั้น หากไม่มีรายการใดที่ต้องดำเนินการ คุณก็ไม่ต้องส่งข้อความแจ้งเตือนเลย หากมีสองรายการที่ต้องดำเนินการ และหนึ่งในนั้นถูกปฏิเสธด้วยเหตุผลเฉพาะ อีเมลก็จะถูกสร้างขึ้นตามข้อเท็จจริงเหล่านั้นโดยอัตโนมัติ

สิ่งนี้