ตัวตนลูกค้า
กำหนดว่าระบบใดสร้าง ID ถาวร และแอตทริบิวต์ใดอัปเดตจากที่อื่นได้
ข้อมูลซ้ำ การควบรวม นิติบุคคล และการเปลี่ยนที่อยู่ได้รับการแก้ไขอย่างไรCRM เทียบ ERP: กำหนดว่าระบบใดเป็นเจ้าของเรคคอร์ดธุรกิจแต่ละรายการ
เปรียบเทียบงานความสัมพันธ์ลูกค้ากับความรับผิดชอบของ ERP ด้านการเงิน สินค้าคงคลัง การจัดซื้อ การจัดส่ง และด้านอื่น ๆ แล้วออกแบบการส่งต่องานแทนการบังคับให้ระบบเดียวเป็นเจ้าของทุกอย่าง
CRM กับ ERP ทับซ้อนกันตรงขอบเขตคำสั่งซื้อของลูกค้า การออกแบบที่ปลอดภัยที่สุดให้แต่ละเรคคอร์ดมีระบบหลักเพียงหนึ่งระบบ และทำให้เห็นข้อยกเว้นตลอดการส่งต่องาน
- CRM เป็นเจ้าของบริบทความสัมพันธ์
- ERP เป็นเจ้าของธุรกรรมที่มีการกำกับ
- Jodoo ประสานงานระหว่างระบบเหล่านี้ได้
CRM และ ERP ตอบคำถามหลักคนละเรื่อง
ขอบเขตควรระบุชัดเจน แม้ผู้ให้บริการรายเดียวจะขายทั้งสองระบบ
| ด้าน | ความรับผิดชอบของ CRM | ความรับผิดชอบของ ERP |
|---|---|---|
| ลูกค้าและบัญชีลูกค้า | บริบทความสัมพันธ์ ผู้มีส่วนได้ส่วนเสีย กิจกรรม ความต้องการ โอกาสการขาย บริบทบริการ และการดำเนินการถัดไป | แอตทริบิวต์หลักของลูกค้าที่จำเป็นต่อการเรียกเก็บเงิน เครดิต ภาษี การจัดส่ง และบัญชี |
| งานเชิงพาณิชย์ | การคัดกรอง ขั้นตอนโอกาสการขาย คำมั่นสัญญาความสัมพันธ์ บริบทข้อเสนอ และข้อมูลคาดการณ์ | รายการที่อนุมัติ ราคา ภาษี เครดิต สัญญา คำสั่งซื้อ การจัดส่ง ใบแจ้งหนี้ การชำระเงิน และรายการบัญชี |
| ฝ่ายปฏิบัติการ | การส่งต่องานที่ลูกค้าเห็น การยกระดับ ความเสี่ยงด้านความสัมพันธ์ และประวัติการสื่อสาร | การจัดซื้อ สินค้าคงคลัง การผลิต การจัดส่ง สินทรัพย์ การเงิน เงินเดือน และการควบคุมตามกฎหมาย |
| การรายงาน | pipeline กิจกรรมความสัมพันธ์ สุขภาพลูกค้า การดำเนินการถัดไป และผลลัพธ์เชิงพาณิชย์ | การรับรู้รายได้ ต้นทุน margin การตีราคาสินค้าคงคลัง เงินสด หนี้สิน และการรวมงบการเงิน |
เขียนกฎผู้รับผิดชอบสำหรับเรคคอร์ดที่ใช้ร่วมกันทุกประเภท
การซิงค์ไม่ใช่ธรรมาภิบาล หากแต่ละช่องและความล้มเหลวไม่มีผู้รับผิดชอบ
ผลิตภัณฑ์และราคา
โดยทั่วไป ERP หรือระบบพาณิชย์เป็นเจ้าของข้อมูลสินค้า ราคา ต้นทุน ภาษี และความพร้อมขาย
CRM แสดงบริบทเชิงพาณิชย์ที่อนุมัติใดได้โดยไม่แก้ไขการส่งต่อคำสั่งซื้อ
กำหนดว่าโอกาสการขายหรือคำขอที่อนุมัติแล้วจะกลายเป็นคำสั่งซื้อ ERP เมื่อใด และใครแก้ไขรายการที่ถูกปฏิเสธ
ต้องมีหลักฐานอะไรบ้างก่อนยอมรับธุรกรรมสถานะและข้อยกเว้น
ส่งสถานะการจัดส่งและการเงินที่เชื่อถือได้กลับมา ขณะที่ยังมีผู้รับผิดชอบติดตามลูกค้า
ใครเห็นธุรกรรมที่ล้มเหลว ล่าช้า มีข้อโต้แย้ง หรือเปลี่ยนแปลง และจะดำเนินการต่อออกแบบเส้นทางจาก CRM ไป ERP และคิวความล้มเหลว
เส้นทางข้อยกเว้นสำคัญกว่าแผนภาพที่สมบูรณ์แบบ
- 01
คัดกรองและอนุมัติ
CRM บันทึกความต้องการและบริบทความสัมพันธ์ ส่วนการทบทวนเชิงพาณิชย์ที่จำเป็นจะยืนยันความพร้อม
- 02
สร้างธุรกรรม
ERP รับข้อมูลลูกค้า สินค้า ราคา ภาษี เครดิต และคำสั่งซื้อที่ผ่านการควบคุม
- 03
ส่งสถานะหลักกลับ
สถานะการจัดส่ง ใบแจ้งหนี้ การชำระเงิน การยกเลิก และเครดิต ไหลกลับมาเพื่อให้มองเห็นฝั่งลูกค้า
- 04
ส่งต่อความล้มเหลว
ข้อผิดพลาดด้านการตรวจสอบ ข้อมูลซ้ำ ข้อมูลหลักขาด เครดิต ความพร้อม และการเชื่อมต่อ เข้าสู่คิวที่มีผู้รับผิดชอบ
- 05
ดำเนินการเรื่องลูกค้าให้เสร็จ
ผู้รับผิดชอบความสัมพันธ์สื่อสารผลลัพธ์และบันทึกการดำเนินการถัดไปโดยไม่เปลี่ยนข้อมูลจริงใน ERP
ใช้ชั้นงานที่กำหนดค่าได้เมื่อขั้นตอนของคนไม่ได้อยู่ใน CRM หรือ ERP ทั้งหมด
Jodoo ไม่ควรแสร้งเป็นบัญชีแยกประเภทหรือแพลตฟอร์มสร้างการมีส่วนร่วมด้านการขายในตัว
คำขอจากลูกค้าหรือคำขอเชิงพาณิชย์ก่อนสร้างธุรกรรม
เลือก
ใช้แบบฟอร์ม การอนุมัติ หลักฐาน และเรคคอร์ดส่งต่องานของ Jodoo รอบ CRM และ ERP
ควรหลีกเลี่ยง
สร้างธุรกรรม ERP ที่ไม่สมบูรณ์เพียงเพื่อเริ่มการทบทวน
การจัดการข้อยกเว้นข้ามทีม
เลือก
ส่งการเชื่อมต่อที่ล้มเหลว ข้อมูลขาด การตัดสินใจราคา ปัญหาจัดส่ง และการติดตามลูกค้า
ควรหลีกเลี่ยง
จัดการการส่งต่องานที่ล้มเหลวผ่านอีเมล
ข้อมูลการเงินและสินค้าคงคลังที่เป็นแหล่งอ้างอิงหลัก
เลือก
ใช้ ERP เป็นแหล่งข้อมูลหลักและแสดงเฉพาะบริบทที่จำเป็น
ควรหลีกเลี่ยง
คำนวณภาษี margin การประเมินมูลค่า หรือเรคคอร์ดตามกฎหมายใหม่ในช่องแอปที่แก้ไขได้
การมีส่วนร่วมด้านการขายและการคาดการณ์ในตัว
เลือก
ใช้ CRM สำเร็จรูปเป็นแหล่งข้อมูลหลัก แล้วเชื่อมงานปฏิบัติการที่อนุมัติแล้ว
ควรหลีกเลี่ยง
สร้างฟีเจอร์การขายเฉพาะทางขึ้นใหม่ในแอปขั้นตอนการทำงานทั่วไป
ปรับเส้นทางข้อยกเว้นโดยไม่ต้องเขียน CRM หรือ ERP ใหม่
การเปรียบเทียบจะเป็นเชิงปฏิบัติเมื่อทีมเปลี่ยนงานข้ามระบบได้ ขณะที่ทั้งสองระบบยังรักษาเรคคอร์ดหลักของตน
การเปลี่ยนแปลงเฉพาะด้านการตรวจสอบ อนุมัติ จัดการข้อยกเว้น และติดตาม อาจต้องผ่านคิวของ CRM, ERP, การเชื่อมต่อ การพัฒนา และการเผยแพร่
ผู้ดูแลระบบที่ผ่านการฝึกมักกำหนดค่าและทดสอบแบบฟอร์มส่งต่องาน เส้นทางอนุมัติ คิวข้อยกเว้น มุมมองผู้รับผิดชอบ และแดชบอร์ดที่ลิงก์แหล่งข้อมูลได้
- เพิ่มการตรวจสอบความพร้อมของคำสั่งซื้อก่อนสร้างใน ERP
- ส่งเคสราคาที่ถูกปฏิเสธหรือข้อมูลหลักที่ขาด
- สร้างมุมมองผู้รับผิดชอบสำหรับการส่งต่องานที่ล้มเหลว
- เพิ่มแดชบอร์ดที่เปิดเรคคอร์ดข้อยกเว้นได้
คำถาม CRM ที่ใช้ได้จริง
ซอฟต์แวร์ CRM ต่างจาก ERP อย่างไร
CRM จัดการความสัมพันธ์ลูกค้าและงานเชิงพาณิชย์เป็นหลัก ส่วน ERP จัดการธุรกรรมและทรัพยากรธุรกิจที่มีการกำกับ เช่น คำสั่งซื้อ สินค้าคงคลัง การจัดซื้อ การผลิต การเงิน และบัญชี
บริษัทจำเป็นต้องมีทั้ง CRM และ ERP หรือไม่
หลายบริษัทจำเป็นต้องมีทั้งสองระบบ เมื่องานที่ลูกค้ามองเห็นและธุรกรรมที่มีการกำกับมีความลึกพอให้แยกระบบ ทีมขนาดเล็กอาจใช้ชุดระบบหรือแพลตฟอร์มกำหนดค่าได้ แต่ผู้รับผิดชอบเรคคอร์ดยังต้องชัดเจน
Jodoo ใช้แทน ERP ได้หรือไม่
Jodoo รองรับคำขอ การอนุมัติ เรคคอร์ด ข้อยกเว้น และแดชบอร์ดที่กำหนดค่าได้ แต่ไม่ใช่สิ่งทดแทนระบบเฉพาะทางด้านบัญชี การตีราคาสินค้าคงคลัง ภาษี เงินเดือน หรือการควบคุม ERP ตามกฎหมาย เว้นแต่ยืนยันแล้วว่าผลิตภัณฑ์มีความสามารถนั้นจริง
ใช้ Jodoo เชื่อมงานระหว่าง CRM กับ ERP
ประสานคำขอ การอนุมัติ หลักฐาน การส่งต่องาน ข้อยกเว้นจากการเชื่อมต่อ และการติดตามลูกค้า ขณะที่ระบบเฉพาะทางแต่ละระบบยังคงเป็นแหล่งข้อมูลหลัก
- คำขอและการอนุมัติก่อนสั่งซื้อ
- คิวข้อยกเว้นระหว่าง CRM–ERP
- ขั้นตอนการทำงานที่ข้ามขอบเขตระบบ
เก็บธุรกรรมหลักไว้ใน ERP และรายละเอียดความสัมพันธ์ไว้ใน CRM
อย่าทำตรรกะด้านการเงิน สินค้าคงคลัง ภาษี การจัดส่ง การคาดการณ์ หรือการมีส่วนร่วมซ้ำ เพียงเพื่อหลีกเลี่ยงการตัดสินใจเรื่องการเชื่อมต่อ
เริ่มใน Jodoo
ใช้พื้นที่ทำงานส่งต่อคำสั่งซื้อ