04 ก.ย. 2568·อ่าน 2 นาที

การตั้งค่าหลายสาขาสำหรับร้านเล็ก: สาขา พนักงาน ลูกค้า

การตั้งค่าหลายสาขาสำหรับร้านเล็ก: โครงสร้างสาขา บทบาทพนักงาน และการแชร์ลูกค้า เพื่อให้แต่ละสาขาเห็นเฉพาะข้อมูลที่จำเป็น

การตั้งค่าหลายสาขาสำหรับร้านเล็ก: สาขา พนักงาน ลูกค้า

ปัญหาที่มักเกิดขึ้นในการตั้งค่าหลายสาขา

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

ความล้มเหลวที่พบบ่อยที่สุดคือการมองเห็นข้อมูลที่ปนกัน พนักงานแผนกต้อนรับที่สาขา A อาจเห็นนัดหมาย บันทึก หรือใบแจ้งหนี้จากสาขา B หรือผู้จัดการพยายามแก้ปัญหาเฉพาะที่แล้วเผลอไปเปลี่ยนการตั้งค่าระดับบริษัทที่กระทบทุกสาขา ช่วงแรกอาจดูสะดวก แต่เร็ว ๆ นี้มันจะกลายเป็นฝุ่นเสียงและความเสี่ยง

"แต่ละสาขาควรเห็นสิ่งที่มันควรเห็น" เป็นแนวคิดง่าย ๆ: พนักงานควรเห็นเฉพาะลูกค้า คำสั่งงาน ตารางเวลา สต็อก และรายงานที่เกี่ยวข้องกับงานและสาขาของพวกเขาเท่านั้น หากทำงานที่สองสาขา เขาควรเห็นทั้งสอง หากเป็นแอดมินระดับภูมิภาค เขาควรเห็นทั้งหมด แต่ต้องเป็นเพราะคุณตั้งค่าไว้ด้วยความตั้งใจ

เมื่อคุณไม่ทำอะไรเลย (หรือพึ่งพากฎไม่เป็นทางการ) ปัญหาที่คาดหมายได้จะเกิดขึ้น:

  • พนักงานแก้ไขเรคคอร์ดผิดเพราะรายการรวมข้อมูลจากหลายสาขา
  • รายละเอียดลูกค้า บันทึก หรือสถานะการชำระเงินรั่วไหลข้ามสาขา
  • รายงานผิดพลาดเพราะยอดรวมผสมสาขาโดยไม่มีตัวกรองชัดเจน
  • ฝ่ายสนับสนุนต้องตอบคำถามแบบเดิม ๆ เช่น “ทำไมฉันเห็นอันนี้?” และ “ฉันหาไม่เจอ” ตลอดวัน

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

ถ้าคุณใช้เครื่องมือแบบไม่ต้องเขียนโค้ด ให้ตัดสินใจกฎเหล่านี้ก่อนสร้างหน้าจอและเวิร์กโฟลว์ มิฉะนั้นคุณจะมาซ่อมสิทธิ์หลังจากที่คนเริ่มใช้งานแล้ว

ส่วนสำคัญที่ต้องกำหนดก่อน

การตั้งค่าหลายสาขาจะทำงานได้ดีขึ้นเมื่อคุณตกลงพื้นฐานไม่กี่ข้อก่อนสร้างหน้าจอ ฟอร์ม หรือรายงาน ถ้าข้ามขั้นตอนนี้ สิทธิ์จะยุ่งเหยิงและข้อมูลไม่เชื่อถือได้

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

ต่อมาตัดสินใจว่าเรคคอร์ดใดเป็นแบบกลุ่ม (global) และใดเป็นของสาขา Global ได้แก่ข้อมูลที่แชร์ทั้งบริษัท เช่น โปรไฟล์ลูกค้า แค็ตตาล็อกสินค้า หรือกฎราคาระดับบริษัท ส่วนของสาขาคือข้อมูลที่เป็นของสาขาหนึ่ง เช่น รายงานเงินสดประจำวัน ตารางงานท้องถิ่น หรือนับสต็อกเฉพาะสาขา

สิทธิ์ต้องมีสองมิติ ไม่ใช่มิติเดียว:

  • ขอบเขต (Scope): ใครเห็นสาขาไหนบ้าง
  • การกระทำ (Action): เขาสามารถทำอะไรกับเรคคอร์ดที่เห็นได้บ้าง

การเข้าถึงอ่านและแก้ไขควรแยกกัน ผู้จัดการภูมิภาคอาจอ่านได้ทุกสาขา แต่แก้ไขได้เฉพาะพนักงานของสาขาตัวเอง พนักงานแผนกต้อนรับอาจอ่านโปรไฟล์ลูกค้าได้ แต่สร้างและแก้ไขนัดหมายได้เฉพาะสาขาของตน

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

การออกแบบสาขาโดยไม่ผูกมัดตัวเอง

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

เริ่มจากคำนิยามที่ชัดเจน

เลือกความหมายเดียวแล้วยึดตามมันในโมเดลข้อมูล ถ้าต้องการแยกแผนกหรือพื้นที่ให้เพิ่มเป็นแนวคิดแยกต่างหากแทนการบรรจุความหมายเพิ่มลงในเรคคอร์ดสาขา

ให้รหัสสาขาที่คงที่ไม่เปลี่ยนแม้ชื่อสาขาจะเปลี่ยน รหัสสั้น ๆ (เช่น "NYC-01") มักใช้งานง่ายกว่าการใช้ที่อยู่หรือชื่อเป็นคีย์

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

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

แนวทางปฏิบัติที่เหมาะคือแบบมีตารางผูกมัด Staff-Branch แยกต่างหาก เพื่อรองรับความสัมพันธ์หนึ่งต่อหลายโดยไม่ต้องแก้ระบบมากในอนาคต

ทำให้การขยายสาขาเป็นเรื่องปกติ

มองว่าการเพิ่มสาขาเป็นการเพิ่มข้อมูล ไม่ใช่กรณีพิเศษ การทดสอบง่าย ๆ คือ: "เราจะเพิ่มสาขาที่ #7 ได้โดยไม่ต้องเปลี่ยนตรรกะไหม?" ในอุดมคติ การเพิ่มสาขาคือการสร้างเรคคอร์ดสาขาใหม่ ตั้งค่าไทม์โซนและชั่วโมงทำการ และมอบหมายพนักงาน หากคุณพบว่าต้องแก้กฎมาก ๆ โมเดลแน่นเกินไป

การเข้าถึงของพนักงาน: บทบาท ขอบเขต และสิ่งที่ทำได้

การตั้งค่าสิทธิ์ที่ดีเริ่มจากแนวคิดเดียว: แยกระหว่างสิ่งที่คนทำได้ (บทบาท) กับสิ่งที่เขาเห็น (ขอบเขต) หากผสมจะจบด้วยการให้สิทธิ์ที่ “ช่วยเหลือ” แล้วกลายเป็นการเปิดเผยข้อมูลเกินจำเป็น

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

รายการตรวจที่ป้องกันความสับสน:

  • ดูเรคคอร์ด
  • สร้างเรคคอร์ดใหม่
  • แก้ไขเรคคอร์ดเดิม
  • ส่งออกหรือดาวน์โหลดข้อมูล
  • การกระทำระดับแอดมิน (จัดการผู้ใช้ เปลี่ยนกฎ ลบข้อมูล)

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

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

ลูกค้าแชร์ร่วมกันโดยไม่เปิดเผยเกินความจำเป็น

ตั้งกฎบทบาทและขอบเขต
กำหนดบทบาทและขอบเขตสาขาตั้งแต่ต้น เพื่อลดการเปิดเผยข้อมูลโดยไม่ตั้งใจ
ลอง AppMaster

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

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

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

ตั้งกฎการมองเห็นให้ชัด

นโยบายง่ายที่สุดคือ: ทุกคนหาเจอลูกค้าได้ แต่ไม่ใช่ทุกคนจะเห็นทุกอย่าง

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

แบบนี้จะทำให้ฐานลูกค้าที่แชร์ใช้งานได้โดยไม่กลายเป็นสมุดบันทึกที่ทุกคนอ่านได้

ปกป้องช่องข้อมูลที่ละเอียดอ่อนโดยออกแบบ

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

ตัวอย่าง: ลูกค้าไปตัดผมที่สาขา 1 และซื้อสินค้าที่สาขา 2 พนักงานสาขา 2 ควรเห็นระดับสะสมคะแนนและการตั้งค่าว่า "แพ้กลิ่น" แต่ไม่ควรเห็นบันทึกคำร้องเรียนโดยละเอียดของสาขา 1

รูปแบบการแยกข้อมูลที่ยังคงเรียบง่าย

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

รูปแบบที่ 1: ฐานข้อมูลเดียว ทุกเรคคอร์ดมี BranchID

นี่เป็นตัวเลือกที่นิยม คำสั่งซื้อ นัดหมาย การนับสต็อก และการกระทำของพนักงานอยู่ในตารางเดียวกัน แต่แต่ละแถวมี BranchID (หรือ LocationID) มันรองรับการแชร์ลูกค้า รายงานข้ามสาขา และพนักงานที่ทำงานหลายสาขา

รูปแบบที่ 2: ฐานข้อมูลแยกต่อสาขา

วิธีนี้อาจรู้สึก "ปลอดภัยกว่า" แต่เพิ่มต้นทุนการดำเนินงาน รายงานทำยากขึ้น และการแชร์ลูกค้าต้องทำการซิงค์หลายทาง

กฎปฏิบัติ:

  • ใช้ฐานข้อมูลเดียวพร้อม BranchID ถ้าต้องการลูกค้าที่แชร์ รายงานรวม และความยืดหยุ่นในการจัดพนักงาน
  • แยกฐานข้อมูลต่อสาขาเฉพาะเมื่อข้อกำหนดทางกฎหมายหรือสัญญาบังคับให้แยกจริง ๆ

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

วางแผนรายการส่วนกลางกับการแทนที่เฉพาะสาขา เก็บนิยามเป็นแบบกลุ่ม (ไอเท็มแค็ตตาล็อก แม่แบบการบริการ กฎราคา) แล้วเพิ่มฟิลด์ให้สาขาแทนการคัดลอกทั้งแค็ตตาล็อกสำหรับแต่ละสาขา

เพิ่มบันทึกการตรวจสอบตั้งแต่ต้น คุณต้องตอบคำถามว่า "ใครเปลี่ยนอะไร และที่ไหน?" อย่างน้อยบันทึก user ID, branch ID, เวลาที่เปลี่ยน, การกระทำ (สร้าง อัปเดต ลบ) และค่าก่อน-หลังสำหรับฟิลด์ที่ละเอียดอ่อน

ขั้นตอนทีละขั้น: ตั้งค่าสาขา สิทธิ์ และกฎการมองเห็น

สร้างหน้าจอที่ผูกกับสาขา
สร้างหน้าจอสำหรับพนักงานที่เริ่มต้นที่สาขาปัจจุบันเพื่อลดความผิดพลาด
สร้างแอป

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

ลำดับการตั้งค่าที่ใช้งานได้จริง

เริ่มบนกระดาษ (หรือสเปรดชีตง่าย ๆ) ก่อนแตะฐานข้อมูลหรือตัวสร้างแอปของคุณ

  1. รวบรวมรายการข้อมูลทุกชิ้นที่เก็บ (นัดหมาย คำสั่งซื้อ สต็อก บันทึกพนักงาน โปรไฟล์ลูกค้า) กำกับแต่ละรายการว่าเป็น global (แชร์) หรือเป็นของสาขา
  2. กำหนดบทบาทเป็นภาษาง่าย ๆ (แผนกต้อนรับ ช่าง ผู้จัดการร้าน สำนักงานใหญ่) สำหรับแต่ละบทบาท เขียนขอบเขตสาขา: สาขาเดียวเท่านั้น สาขาที่มอบหมาย หรือทุกสาขา
  3. ตั้งกฎสำหรับลูกค้าที่แชร์: อะไรเห็นได้ข้ามสาขา อะไรเก็บท้องถิ่น ใครแก้ไขฟิลด์ที่แชร์ได้
  4. ออกแบบหน้าจอและรายงานต่างกันสำหรับพนักงานและผู้จัดการ มุมมองพนักงานควรเริ่มต้นที่ "สาขาของฉัน" มุมมองผู้จัดการมีตัวกรองและการเปรียบเทียบ
  5. ทดสอบด้วยบัญชีตัวอย่างจากหลายสาขา ทำงานจริง (สร้างการจอง คืนเงิน อัปเดตลูกค้า ดูรายงาน) ยืนยันว่าระบบบล็อกสิ่งที่ควรถูกบล็อก

อย่าข้ามการทดสอบ ปัญหาสิทธิ์ส่วนใหญ่ปรากฏเมื่อคุณล็อกอินเป็นบทบาทจริงและลองทำงานประจำอย่างรวดเร็ว

ความผิดพลาดทั่วไปและวิธีหลีกเลี่ยง

แชร์ลูกค้า แต่เก็บบันทึกไว้ท้องถิ่น
เก็บโปรไฟล์ลูกค้าแบบแชร์ร่วมกัน แต่ให้การเยี่ยมและบันทึกเป็นข้อมูลของสาขา
ออกแบบข้อมูล

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

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

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

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

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

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

การแก้ไขเชิงปฏิบัติที่ควรทำตั้งแต่ต้น:

  • เขียนกฎสำหรับแต่ละประเภทข้อมูล: global (แชร์) vs branch-only
  • กำหนดบทบาทตามการกระทำ แล้วเพิ่มขอบเขตสาขา (สาขาเดียว vs หลายสาขา)
  • ฝังตัวกรองสาขาในทุกรายการ รายงาน และการส่งออก
  • เก็บบันทึกของสาขาและข้อมูลลูกค้าที่แชร์แยกกัน
  • บันทึกการแก้ไข (ผู้ใช้ + เวลา) สำหรับการเปลี่ยนแปลงลูกค้าและคำสั่งซื้อ

ตรวจสอบด่วนก่อนเปิดใช้งานจริง

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

ใช้เช็คลิสต์นี้เพื่อตรวจหาปัญหาที่สร้างความสับสนมากที่สุด:

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

แล้วทดสอบสถานการณ์หนึ่งที่เป็นมุม: ลูกค้าซื้อที่สาขา A แล้วโทรมาที่สาขา C เพื่อขอความช่วยเหลือ พนักงานสาขา C ควรเห็นโปรไฟล์ลูกค้าที่แชร์ แต่ไม่ควรเห็นบันทึกภายในหรือเรคคอร์ดที่ถูกจำกัดของสาขา A

ตัวอย่างสถานการณ์: ลูกค้าเดียว สามสาขา

เว็บและมือถือสำหรับทุกสาขา
สร้างแดชบอร์ดเว็บและแอปมือถือจากโปรเจกต์ no-code เดียวกันสำหรับทุกสาขา
เริ่มโปรเจกต์

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

Maya (พนักงานต้อนรับที่ Downtown) เปิดระบบ เธอเห็นปฏิทินของ Downtown เท่านั้น พนักงานของ Downtown และการนัดหมายวันนี้ เธอค้นหาลูกค้าได้ข้ามสาขา แต่เห็นแค่ข้อมูลโปรไฟล์พื้นฐาน: ชื่อ เบอร์ติดต่อ การแพ้ และสถานะสะสมคะแนน เธอไม่เห็นตาราง Riverside ผลการทำงานของพนักงาน หรือบันทึกส่วนตัวของสาขาอื่น

Alex (เจ้าของ) เข้าระบบ Alex เห็นปฏิทินทั้งสามสาขา รายงานรายได้แยกสาขา และจัดการบทบาทพนักงาน Alex ยังอนุมัติข้อยกเว้นเช่นส่วนลดใหญ่ได้

Jordan มักไป Downtown แต่สัปดาห์นี้จองตัดผมที่ Mall เมื่อ Mall เช็กอิน Jordan เขาเห็นโปรไฟล์หลักและประวัติการให้บริการ (ทำอะไร เมื่อไร และโดยใคร) หลังการบริการ Mall เพิ่มบริการใหม่ในประวัติ Jordan Downtown จะเห็นต่อไป จึงไม่ต้องถามซ้ำหรือให้คำแนะนำผิด

จุดที่ซับซ้อนคือการชำระเงิน Jordan ขอส่วนลด 30% เพราะรอนาน แผนกต้อนรับของ Mall สามารถป้อนคำขอส่วนลดได้ แต่ไม่สามารถอนุมัติเกิน 10% คำขอจะถูกส่งไปหา Alex เพื่ออนุมัติ Alex อนุมัติ ใบเสร็จอัปเดต และบันทึกการตรวจสอบแสดงว่าใครขอและใครอนุมัติ

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

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

ขั้นตอนต่อไป: จดกฎ ทดสอบสิทธิ์ แล้วเริ่มสร้าง

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

มุ่งหาประโยคสั้น ๆ 10–15 ข้อที่ครอบคลุมกรณีประจำวัน: การจอง โปรไฟล์ลูกค้า การชำระเงิน คืนเงิน บันทึก และรายงาน เช่น:

  • พนักงานเห็นลูกค้าและคำสั่งของสาขาตัวเองได้
  • ข้อมูลติดต่อของลูกค้าเห็นได้ทุกสาขา แต่บันทึกเป็นของสาขา
  • ผู้จัดการดูรายงานสาขาได้; เฉพาะเจ้าของดูยอดรวมทุกสาขาได้
  • การคืนเงินต้องได้รับอนุมัติจากผู้จัดการและต้องเกิดในสาขาเดียวกัน
  • เฉพาะ HQ แก้ไขรายการราคาและการตั้งค่าระดับโลกได้

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

ทดสอบด้วยบทบาทจริง ไม่ใช่บัญชีแอดมิน สร้างผู้ใช้ทดสอบสามคน (แคชเชียร์ ผู้จัดการ HQ) และเดินตามฟลว์สมจริง: ลูกค้าโทรเข้าสาขา A ไปเยี่ยมสาขา B สัปดาห์หน้า และขอคืนเงินที่สาขา C ยืนยันว่าทุกคนเห็นแค่สิ่งที่ต้องการ

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

ถ้าคุณกำลังสร้างเครื่องมือภายในแบบกำหนดเอง AppMaster (appmaster.io) สามารถช่วยคุณออกแบบสาขา บทบาท และกฎธุรกิจในที่เดียว แล้วสร้างโค้ดใหม่เมื่อความต้องการเปลี่ยน เพื่อให้กฎสิทธิ์คงที่เมื่อคุณเติบโต

ง่ายต่อการเริ่มต้น
สร้างบางสิ่งที่ น่าทึ่ง

ทดลองกับ AppMaster ด้วยแผนฟรี
เมื่อคุณพร้อม คุณสามารถเลือกการสมัครที่เหมาะสมได้

เริ่ม
การตั้งค่าหลายสาขาสำหรับร้านเล็ก: สาขา พนักงาน ลูกค้า | AppMaster