AI Concierge สำหรับเครือโรงแรมระดับภูมิภาค — เก็บลีดสะสม 370 ราย บอทจัดการเองได้ 92-96.8% สาขาที่สองเสร็จในครึ่งเวลา

ลูกค้า

ร้านค้าออนไลน์ที่ขายอาหารเสริมนำเข้าผ่าน marketplace 5 ร้าน จาก 2 แพลตฟอร์ม สั่งสินค้าจากต่างประเทศเองเป็นสกุลดอลลาร์ และใช้ PEAK Account เป็นระบบบัญชีหลัก ในระบบบัญชีมีสินค้า 1,339 รายการ และคู่ค้า 178 ราย

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

ทั้งหมดถูกคีย์เข้าโปรแกรมบัญชีด้วยมือ ทีละใบ ทุกวัน

ปัญหา: คีย์ผิดประเภทเดียว = ยื่นภาษีผิด

ปัญหาของงานนี้ไม่ใช่ปริมาณ แต่เป็นจำนวนกฎภาษีที่ต้องถูกพร้อมกันในบิลใบเดียว

ทั้ง 7 กรณีนี้ต้องแยกออกจากกันให้ถูก ตั้งแต่ตอนอ่านบิล

และนอกจากนั้น:

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

สิ่งที่เสียไป ถ้าปล่อยไว้

เวลาที่เสียไปกับการคีย์ยังพอรับได้ แต่บิลที่คีย์ผิดประเภทภาษี จะไม่ปรากฏตัวจนกว่าจะถึงรอบยื่น และตอนนั้นการย้อนกลับไปแก้ทีละใบ แพงกว่าการคีย์ใหม่ทั้งหมด

ทำไมเลือกวางระบบเสริมบนของเดิม แทนการเปลี่ยนระบบ

ลูกค้าเข้ามาโดยรู้อยู่แล้วว่าต้องการอะไร — ระบบที่คีย์บิลเข้าโปรแกรมบัญชีที่เขาใช้อยู่ ไม่ใช่โปรแกรมบัญชีตัวใหม่

1. •ผังบัญชีและประวัติทั้งหมดอยู่ในโปรแกรมเดิมแล้ว — การย้ายคือการทิ้งของเก่า
2. •ต้องการให้ระบบเสนอ แต่คนเป็นคนตัดสิน — ไม่ยอมให้ AI คีย์เข้าสมุดบัญชีเองตามลำพัง
3. •ต้องการเป็นเจ้าของระบบเอง — เลือกติดตั้งบนเครื่อง mini PC ที่ออฟฟิศ ไม่ต้องจ่ายค่าโฮสต์รายเดือน
4. •ต้องการให้แนบไฟล์ต้นฉบับเข้าเอกสารบัญชีด้วย — เพื่อให้ตรวจย้อนได้

ก่อนเสนอราคา ผมตรวจสอบช่องทางบันทึกรายจ่ายจริงของ PEAK โดยตรงก่อนว่ารองรับทุกอย่างที่ต้องการหรือไม่ — หลายรายการต่อใบ หัก ณ ที่จ่าย สกุลเงินต่างประเทศ ใบกำกับภาษี สถานะชำระเงิน แนบไฟล์ ผลคือรองรับครบ ไม่มีหมวดใดติดข้อจำกัด

บทสนทนาที่ยากที่สุดในโครงการ: ข้อเสนอให้เปลี่ยนเครื่องอ่านเอกสาร

ระหว่างที่ระบบติดปัญหาตอน go-live ลูกค้าเสนอให้เปลี่ยนไปใช้บริการ OCR อีกเจ้าหนึ่ง "เพื่อให้ถูกกว่าโมเดลที่แพง"

เราปฏิเสธ พร้อมเหตุผลที่ตรวจสอบจากเอกสารของผู้ให้บริการรายนั้นเอง:

• •บริการนั้นทำ OCR อย่างเดียว — แปลงภาพเป็นข้อความและโครงสร้างหน้า
• •มัน ไม่ได้ดึงข้อมูลเป็นฟิลด์ และไม่ได้จัดหมวดค่าใช้จ่าย — ซึ่งคือ 2 ใน 3 งานที่ระบบนี้ต้องทำ
• •ถ้าเปลี่ยนไปใช้ ก็ยังต้องมี AI อีกชั้นมาทำงานที่เหลืออยู่ดี และบริการนั้นคิดเงินเป็นรายหน้า = ต้นทุนเพิ่ม ไม่ใช่ลด
• •และข้อสมมติตั้งต้นก็ผิด — ที่ปริมาณราว 10 ใบ/วัน ค่าโมเดลแทบไม่มีนัยสำคัญ ปัญหาตอนนั้นคือความพร้อมให้บริการ ไม่ใช่ราคา

การเปลี่ยนเครื่องยนต์กลางคันคือการรื้อสถาปัตยกรรม ไม่ใช่การแก้ปัญหา go-live — เราจึงบอกตรงๆ ว่าถ้ายืนยันจะเปลี่ยน มันเป็นงานใหม่ที่มีค่าใช้จ่าย ไม่ใช่การแก้บั๊ก

การเปลี่ยนโมเดลอ่านเอกสาร ที่ทดสอบใหม่ทั้งชุดก่อนยืนยัน

ก่อนส่งมอบจริง ตัวอ่านบิลถูกย้ายไปใช้โมเดลที่ลูกค้ามีสิทธิ์ใช้อยู่แล้ว เราไม่ได้ย้ายแล้วหวังว่าจะเหมือนเดิม — ทดสอบใหม่ทั้งชุด ผลคืออ่านถูกครบ 12 จาก 12 ประเภทบิล และทดสอบทะลุปลายทางจนเกิดเอกสารจริงในโปรแกรมบัญชี

ทำไมเลือกให้คนยืนยันก่อนคีย์ทุกใบ ไม่ใช่ auto-post

แนวคิดหลักข้อเดียว: สมุดบัญชีคือของจริง ไม่ใช่ที่ทดลอง — AI อ่าน จัดประเภท จับคู่ คำนวณภาษี และแปลงค่าเงินให้เสร็จ แล้วหยุดรอปุ่มเดียว

ทุกใบมีข้อความสรุปให้ตรวจ พร้อมคำเตือน [โปรดตรวจ] กำกับจุดที่ AI ไม่มั่นใจ

จุดตัดสินใจนี้ตามมาจากข้อเท็จจริงเดียว — PEAK ของลูกค้าเป็นระบบใช้งานจริงล้วนๆ ไม่มีระบบทดลองแยกให้ลองผิดลองถูกอย่างปลอดภัย ทุกเอกสารจึงถูกบันทึกเป็นสถานะร่างก่อนเสมอ และต้องมีคนกดยืนยันผ่านช่องทางส่วนตัวก่อนคีย์เข้าบัญชีจริงทุกใบ ระบบจะไม่คีย์เข้าบัญชีจริงเองโดยไม่มีคนตรวจ ไม่ว่าจะมั่นใจแค่ไหน ความเสี่ยงจึงถูกออกแบบให้ตกอยู่ที่ "รอความเห็นชอบก่อน" ไม่ใช่ "เดาแล้วหวังว่าไม่ผิด"

การสร้างระบบแบ่งเป็น 3 เฟส แต่ละเฟสต้องพิสูจน์ความสามารถใหม่กับเอกสารจริงก่อนเดินหน้าต่อ — เฟสแรกพิสูจน์การจัดหมวดเอกสารจริงที่ส่งผ่านช่องทางส่วนตัว เฟสสองต่อการจัดหมวดนั้นเข้ากับการคีย์จริงเข้า PEAK ตรวจสอบทีละบรรทัดเทียบกับเอกสารมาตรฐานที่ PEAK สร้างเอง เฟสสามปิดจุดเสี่ยงที่เหลือ (ใบลดหนี้ แนบไฟล์ ย้ายระบบไปติดตั้งที่เครื่องลูกค้าเอง) ก่อนส่งมอบ

เส้นทางของบิลหนึ่งใบ

การตัดสินใจทางเทคนิคที่กำหนดคุณภาพของงาน

สิ่งที่ส่งมอบ

• •รับบิลผ่านแชท พร้อมตัวอ่านด้วย AI
• •จัดประเภทอัตโนมัติเข้าผังบัญชีที่ตกลงกัน (สินค้า / ค่าอาหาร / วัสดุสิ้นเปลืองแยกขาย-บริหาร / ค่าขนส่ง / ค่าจ้าง / ค่าเดินทาง / ค่าทำบัญชี / ค่าอินเทอร์เน็ต / ค่าธรรมเนียม marketplace / ปัดเศษ)
• •จับคู่คู่ค้า 178 ราย จากเลขผู้เสียภาษีหรือชื่อร้าน — ระบุเองผ่านแคปชันได้
• •จับคู่สินค้ากับแคตตาล็อก 1,339 รายการ — ใส่รหัสในแคปชันได้ คั่นด้วย + จับได้ทั้งรหัสภายใน บาร์โค้ด และรหัสของซัพพลายเออร์
• •ตรรกะภาษีครบตามตารางด้านบน
• •แปลงค่าเงินตามอัตรา ธปท. + บันทึกอัตราที่ใช้ลงชีต
• •ปุ่มยืนยันก่อนคีย์ทุกใบ
• •สร้างเอกสารในโปรแกรมบัญชีผ่าน API + แนบไฟล์ต้นฉบับ (ไม่เกิน 5 MB แนบตรง ใหญ่กว่านั้นแนบเป็นลิงก์)
• •หมุนแท็บและโฟลเดอร์รายเดือนอัตโนมัติ — แต่ฐานข้อมูลสินค้าและคู่ค้าไม่หมุน เพราะเป็นข้อมูลถาวร
• •แท็บสรุปบัญชีรายเดือน (ก่อน VAT / VAT / WHT / รวม / จำนวนเอกสาร)
• •บันทึกประวัติการคีย์ทุกใบ — ผู้ขาย ไปคู่ค้า ไปบัญชี ไปเลขเอกสาร เป็นหลักฐานตรวจย้อน ไม่ใช่ระบบเรียนรู้ (ดูหมายเหตุ)
• •จดจำรหัสสินค้าอัตโนมัติ — เมื่อจับคู่จากชื่อแล้วบิลมีรหัสใหม่ ระบบบันทึกกลับเข้าฐานข้อมูล โดยไม่ทับรหัสเดิม
• •ระบบแจ้งเตือนเมื่อเกิดข้อผิดพลาด แยกเป็น workflow ต่างหาก
• •ชุดติดตั้งทำเอง + คู่มือใช้งานภาษาไทย + คู่มือย้ายระบบ

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

ผลลัพธ์

1. อ่านบิลถูกต้องครบ 12 จาก 12 ประเภท และสร้างเอกสารจริงในระบบบัญชีได้

บิลที่ธุรกิจนี้เจอมีหลายแบบมาก ตั้งแต่ใบกำกับภาษีเต็มรูป ไปจนถึงสลิปร้านสะดวกซื้อและใบแจ้งหนี้ต่างประเทศ การทดสอบหลังย้ายโมเดลอ่านเอกสาร พบว่า อ่านถูกครบ 12 จาก 12 ประเภท และทดสอบทะลุปลายทางจนเกิดเอกสารจริงในโปรแกรมบัญชี

แปลว่าสิ่งที่ส่งมอบไม่ใช่ตัวอย่างสาธิต แต่คือระบบที่แตะสมุดบัญชีจริงได้อย่างถูกต้อง

2. กวาดทดสอบ 48 ไฟล์จริง ผ่าน 45 ไม่มี ERROR — และแก้อีก 4 จุดหลังส่งมอบ

ก่อนปิดงาน ระบบถูกกวาดทดสอบด้วยเอกสารจริงของลูกค้าทั้ง 48 ไฟล์ (57 ครั้งรวมการทดสอบซ้ำ) ไม่ใช่ไฟล์ตัวอย่าง การกวาดรอบนั้นเจอของจริง 4 จุด ที่ไม่มีใครเจอตอนทดสอบทีละใบ:

ผลหลังแก้: ผ่าน 45 จาก 48 · ERROR 0 · FAIL 2 และ 2 กรณีที่เหลือไม่ใช่บั๊กของระบบ — ใบสแกนที่อ่านชื่อร้านไม่ออก (วิธีแก้: พิมพ์รหัสบัญชีกำกับในแคปชัน) และบิลที่รอลูกค้ายืนยันรหัสบัญชี

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

3. วัดการจับคู่สินค้ากับแคตตาล็อกจริงทั้ง 1,339 รายการ ได้ 90.4%

การจับคู่สินค้าคือจุดที่ระบบแบบนี้พังเงียบที่สุด

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

และยืนยันครบวงจรด้วยเอกสารบิลต่างประเทศจริงจากผู้ขายรายหนึ่ง — แปลงอัตราแลกเปลี่ยนถูกต้อง คีย์เข้า PEAK ถูกต้อง และยืนยันชำระเต็มจำนวนแล้ว

เบื้องหลัง go-live: สองวันที่ระบบเงียบ และสาเหตุจริงที่ไม่มีใครเดาถูก

ลูกค้าเลือกติดตั้งระบบบนเครื่องของตัวเอง ซึ่งแปลว่าเราแก้อะไรให้ไม่ได้เลยนอกจากบอกทาง — และมันไม่ได้ราบรื่น

ด่านที่ 1 — สิทธิ์เข้าถึง ไม่ใช่การตั้งค่า ระบบขึ้น Forbidden ตอนโหลดฐานข้อมูลคู่ค้า อาการเหมือนตั้งค่าผิด แต่สาเหตุจริงคือบัญชี Google ของลูกค้ายังไม่มีสิทธิ์เข้าไฟล์ฐานข้อมูล แก้ด้วยการแชร์สิทธิ์ ไม่ใช่แก้โหนด

ด่านที่ 2 — "ส่งไฟล์แล้วไม่ทำงาน" ลูกค้ากด Execute ผ่านแล้ว แต่ส่งบิลจริงกลับเงียบ เพราะ Execute คือการทดสอบด้วยมือ ระบบจะฟังข้อความจริงก็ต่อเมื่อ Publish แล้วเท่านั้น

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

ด่านที่ 4 — โหนดอ่านเอกสารพัง และการเดาที่ผิด เราเดาตั้งต้นว่าเป็นปัญหาคีย์หรือ API ไม่ได้เปิด เดาผิด — รหัสข้อผิดพลาดจริงคือ 503 ซึ่งแปลว่าคำขอไปถึงปลายทางแล้ว คีย์ สิทธิ์ และการตั้งค่าของลูกค้าถูกต้องหมดตั้งแต่แรก ปัญหาคือฝั่งผู้ให้บริการโมเดลรับไม่ไหวในช่วงกลางวัน

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

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

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

หลักฐานปิดงาน ไม่ใช่คำบอกเล่า: แถวในชีตใช้งานจริง 2 แถว เวลา 21:31:45 และ 21:53:57 พร้อมเลขเอกสารจริงจากโปรแกรมบัญชีทั้งคู่ ส่วนแถวเปล่าที่ไม่มีเลขเอกสารเมื่อช่วงเย็น คือร่องรอยของความพยายามด้วยคีย์ฟรีในเวลาเร่งด่วน

ระหว่างทางมีอีกหนึ่งการเดาที่ผิดแล้วถูกจับได้ — เคยสงสัยว่าเป็นเพราะรูปแบบไฟล์ PDF ทั้งที่ PDF ใช้งานได้ปกติมาตั้งแต่งวด 1 บันทึกไว้เป็นความผิดพลาด ไม่ใช่ลบทิ้ง

ความโปร่งใส — สิ่งที่เจอหลัง Go-Live

ในช่วงประกันฟรี 30 วัน การรันบนคอมพิวเตอร์และเครือข่ายของลูกค้าเอง (แทนโครงสร้างพื้นฐานที่ผู้พัฒนาดูแลโดยตรง) เผยปัญหาบางจุดที่ไม่เคยเจอตอนทดสอบ — เครือข่ายขาดหายชั่วคราวเมื่อสะดุด เอกสารสแกนคุณภาพต่ำบางไฟล์อ่านยากขึ้น และกรณีภาษีที่ไม่ค่อยเจอบางแบบ (เช่นค่าขนส่งบางประเภทที่ไม่ต้องหัก ณ ที่จ่าย) ทั้งหมดแก้ไขและยืนยันซ้ำด้วยเอกสารจริงระหว่างช่วงประกัน ขั้นตอนยืนยันก่อนคีย์ทุกใบทำให้ไม่มีปัญหาข้อใดหลุดเข้าบัญชีจริงโดยไม่มีคนตรวจ — ไม่มีรายการบัญชีผิดเข้าระบบโดยไม่ได้รับการยืนยันเลย

งานที่ถอนออก และไม่คิดเงิน

หลังส่งมอบ ลูกค้าจ้างต่อให้ทำระบบตัดสต๊อก งานนั้นถูกสร้างและทดสอบจนพบว่า API ฝั่งโปรแกรมบัญชีตอบกลับว่าสำเร็จ โดยที่ไม่ได้ทำงานจริง — สต๊อกไม่ขยับแม้เอกสารจะถูกอนุมัติแล้ว

ผลคือถอนขอบเขตงานนั้นออก และไม่คิดเงินสักบาท พร้อมส่งหลักฐานการทดสอบให้ลูกค้าดู

บทเรียนที่ได้

• •ไม่มีระบบทดลองแยกต่างหาก จึงให้ทุกอย่างเป็นสถานะร่างก่อนเสมอ — PEAK เป็นระบบใช้งานจริงล้วนๆ ทางออกที่ใช้ได้จริงไม่ใช่ "เขียนโค้ดให้ระวังขึ้น" แต่คือให้บันทึกเป็นร่างเสมอ บวกคนกดยืนยันก่อนแตะบัญชีจริงทุกใบ
• •เครื่องมือที่ถูกกว่าที่ลูกค้าอยากเปลี่ยนไปใช้ ต้องพิสูจน์ว่าทำงานได้จริงก่อนเสมอ — ข้อเสนอหนึ่งถูกปฏิเสธด้วยหลักฐานจากเอกสารของผู้ให้บริการเอง (ทำ OCR อย่างเดียว ไม่ดึงฟิลด์ ไม่จัดหมวด และคิดเงินรายหน้า) ส่วนการเปลี่ยนโมเดลช่วงใกล้ go-live ทดสอบตรงกับผู้ให้บริการก่อนพบว่าอ่านรูปภาพไม่ได้เลย และโมเดลอื่นที่อ่านรูปได้กลับอ่าน PDF ตรงๆ ไม่ได้ สุดท้ายโมเดลที่เลือกใช้จริงอ่านได้ทั้งสองแบบและผ่านทดสอบเอกสารจริง 12/12 ก่อนอนุมัติ
• •ติดตั้งบนเครื่องของลูกค้าเองเผยปัญหาที่เครื่องทดสอบของผู้พัฒนาไม่เคยเจอ — ไฟล์บันทึกชนกันจนได้ไฟล์ว่างเปล่าบางครั้ง และการส่งเอกสารรัวๆ ทำให้ถูกจำกัดการเชื่อมต่อชั่วคราว ทั้งสองจุดไม่โผล่ตอนทดสอบทีละใบบนเครื่องผู้พัฒนาเอง ต้องกันไว้ก่อน go-live
• •สามอาการที่มาพร้อมกัน มีค่ามากกว่าหนึ่งอาการที่เสียงดัง — ไม่มีบันทึกการทำงาน เงียบสนิท และยอดคงเหลือไม่ลด สามข้อนี้รวมกันแปลว่าบิลไม่เคยเข้าระบบ ซึ่งย้ายทิศการไล่ปัญหาทั้งหมดจากโหนดอ่านเอกสารไปที่ webhook
• •คีย์ฟรีที่ทำงานตอนกลางคืนและพังตอนบ่าย หน้าตาเหมือนระบบพังทุกประการ — การเปิดการชำระเงินกับคีย์ตัวหนึ่ง ไม่ได้อัปเกรดคีย์อีกตัว ต้องเช็คว่าระบบที่รันอยู่ถือคีย์ตัวไหนจริงๆ
• •เส้นแบ่งระหว่าง "อยู่ในแพ็กเกจเดิม" กับ "ต้องเพิ่มเงิน" ต้องชัดตั้งแต่วันแรก — เอกสารจริงมีมากกว่า 12 รูปแบบ ไม่ใช่จำนวนหมวดที่ประเมินไว้ตอนเสนอราคา เอกสารที่หลักการคิดภาษีเหมือนเดิมต่างแค่บัญชีปลายทางยังอยู่ในแพ็กเกจเดิม แต่เอกสารที่มีหลักการคิดภาษีแบบใหม่จริงๆ ถือเป็นส่วนต้องออกแบบเพิ่ม
• •ตัวเลขความแม่นยำมีความหมายก็ต่อเมื่อวัดจากเอกสารจริงของลูกค้า — 93.75% มาจากการทดสอบซ้ำหลายรอบกับไฟล์จริงที่บริษัทส่งมาเอง และ 90.4% มาจากแคตตาล็อกจริงทั้ง 1,339 รายการ ไม่ใช่การสุ่ม ซึ่งเป็นเหตุผลที่มันไปแทนที่ตัวเลขประมาณการเดิมที่ต่ำกว่าความจริง
• •แก้เอกสารของตัวเองเมื่อมันพูดเกินจริง — คู่มือเคยเขียนว่าระบบจำร้านได้เองเมื่อเวลาผ่านไป ซึ่งไม่จริง เราแก้ก่อนส่งมอบ แทนที่จะปล่อยไว้เพราะมันฟังดูดี