อย่าสร้าง บูรณาการ – คู่มือการบูรณาการ CRM

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

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

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

นี่คือจุดที่การรวมระบบของบุคคลที่สามมีประโยชน์ มาดูว่าเราจะหลีกเลี่ยงหลุมพรางทั่วไปได้ไหม

การบูรณาการ CRM

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

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

รวมแผนกเทคนิคของคุณในการตัดสินใจ

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

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

อย่างไรก็ตาม มีบางหัวข้อที่อาจเป็นประโยชน์ที่จะพูดคุยก่อนตัดสินใจ หัวข้อทั่วไปเช่น “เราต้องการสิ่งนี้เลยหรือไม่” จำเป็นต้องได้รับการแก้ไข แต่ก็เป็นความคิดที่ดีที่จะมีแนวคิดอยู่แล้วว่าขอบเขตคืออะไร จำเป็นต้องมีการซิงค์แบบสองทางหรือระบบของบุคคลที่สามจะทำตามระบบการสั่งซื้อหรือไม่? เมื่อขอบเขตไม่อยู่ในแนวทางแล้ว ก็จำเป็นต้องมีการอภิปรายทางเทคนิคเกี่ยวกับรายละเอียดการใช้งาน เช่น เว็บฮุคหรือการประเมินขีดจำกัดของ API

คุณต้องการการผสานรวมแบบกำหนดเองหรือไม่?

เมื่อพูดถึงการรวมระบบ ไม่น่าแปลกใจที่มีแพลตฟอร์มที่มีอยู่แล้วที่สัญญาว่าจะแก้ปัญหาบางอย่างที่คุณน่าจะพบ ปัจจุบัน Zapier และ IFTTT มีแนวโน้มดีที่สุด

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

และแม้ว่าจะเป็นการผสานรวมข้อมูลที่กำหนดเอง (สั่งโรบ็อตและราคาของมัน) Zapier Webhooks สามารถทำหน้าที่เป็นคนกลางสำหรับการผสานรวมของคุณได้

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

ซึ่งนำฉันไปสู่จุดต่อไปของฉัน

คุณต้องการซิงค์สองทางหรือไม่?

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

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

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

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

คุณจะได้รับแจ้งการเปลี่ยนแปลงจาก CRM อย่างไร

หากคุณตัดสินใจที่จะทำการซิงค์แบบสองทาง จะมีคำถามติดตามผล: คุณรู้ได้อย่างไรว่ามีการเปลี่ยนแปลงบางอย่างในด้าน CRM

ผู้ให้บริการระบบส่วนใหญ่มีเครื่องมือสำหรับสิ่งนี้ แต่สิ่งที่ดีที่สุดสำหรับการเปลี่ยนแปลงในทันทีคือเว็บฮุค—โดยพื้นฐานแล้ว ระบบการแจ้งเตือน HTTP ที่สามารถกำหนดค่าเพื่อแจ้งให้คุณทราบเกี่ยวกับการเปลี่ยนแปลงที่เกี่ยวข้อง (สำหรับบางระบบ แม้จะเป็นแบบฟิลด์ต่อฟิลด์) .

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

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

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

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

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

ข้อมูลของคุณอยู่ในสภาพดีหรือไม่?

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

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

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

ข้อจำกัดของ API

สุดท้ายนี้ ข้อจำกัดของ API เป็นสิ่งที่ต้องแก้ไขโดยเร็วที่สุด

สมมติว่ามี API (ซึ่งโดยพื้นฐานแล้วเป็นสิ่งที่ต้องมีสำหรับการผสานรวมใดๆ) การพิจารณาข้อจำกัดของ API จะเป็นประโยชน์อย่างยิ่ง สตาร์ทอัพส่วนใหญ่สามารถรับมือกับขีดจำกัด API พื้นฐานของระบบ CRM ส่วนใหญ่ได้ ตัวอย่างเช่น HubSpot เสนอการเรียก API 250,000 ครั้งต่อระยะเวลา 24 ชั่วโมงแม้ในระดับฟรี ในทางกลับกัน มันยังจำกัดการโทรที่ 10 ต่อวินาที (100 ถ้าคุณใช้ OAuth) ผู้นำตลาด Salesforce อนุญาตเพียง 100,000 ทุก ๆ 24 ชั่วโมง แต่เสนอให้ซื้อเพิ่มเติม

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

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

การใช้งาน CRM

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

ยังคงมีแนวทางปฏิบัติที่ดีที่สุดสองสามข้อที่ต้องปฏิบัติตามในระหว่างขั้นตอนการใช้งาน

ลองใช้ทุกอย่างในสภาพแวดล้อมการทดสอบ

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

มีปัญหาสองสามประการเกี่ยวกับวิธีการนี้:

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

   

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

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

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

กำหนด ID สำหรับการจับคู่เอนทิตี

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

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

ดังนั้น แก้ไขตารางการติดต่อของคุณด้วยคอลัมน์ที่ชื่อว่า crm_id หรือ external_id วิธีการนี้มีข้อดีสองสามข้อ:

• เนื่องจากเป็น ID จึงไม่เปลี่ยนแปลง (ต่างจากที่อยู่อีเมลหรือหมายเลขโทรศัพท์)
• คุณสามารถดูได้ว่าคุณจำเป็นต้องสร้างหรืออัปเดตเอนทิตีโดยไม่ต้องทำการเรียก API ก่อนหรือไม่ (หากฟิลด์ ID ภายนอกว่างเปล่า คุณสามารถถือว่าผู้ติดต่อไม่มีอยู่จริง)

ก่อน:

หลังจาก:

ตัวอย่างเช่น สมมติว่าคุณเป็นนักพัฒนา Ruby on Rails ที่ทำงานเกี่ยวกับแอปพลิเคชันที่ต้องการซิงค์ลูกค้าเดิมและลูกค้าใหม่กับ HubSpot

ตัวอย่างโค้ดแบบง่ายอาจมีลักษณะดังนี้:

 class HubspotSync def sync(customer) hubspot_return = if customer.hubspot_id.present? update(customer, customer.hubspot_id) else create(customer) end customer.update(hubspot_id: hubspot_return['companyId']) end private def create(customer) response = HTTParpty.post("https://api.hubapi.com/companies/v2/companies", map(company)) handle_response(response) end def update(customer, hubspot_id) response = HTTParpty.put("https://api.hubapi.com/companies/v2/companies/#{hubspot_id}", map(company)) handle_response(response) end def handle_response(response) raise RuntimeError, "Unexpected Status code: #{response.code}" if response.code >= 500 JSON.parse(response.body) end def map(company) # mapping code goes here { properties: [ name: 'name', value: company.name ] } end end

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

เมื่อเป็นเรื่องของการทำแผนที่ ไปที่ Freestyle

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

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

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

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

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

พิจารณาลองใหม่อีกครั้ง

มาลงที่ระดับเทคนิคกันดีกว่า: การใช้การซิงค์จริงระหว่างระบบของคุณกับ CRM เกือบจะถือว่าการผสานรวมจะเกิดขึ้นผ่านการเชื่อมต่อ HTTP ระบบส่วนใหญ่มี HTTP API และภาษาการเขียนโปรแกรมทั้งหมดจะช่วยให้คุณสามารถเรียก HTTP ได้ง่ายมาก

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

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

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

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

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

 class HubspotSyncJob < ApplicationJob def perform(customer) HubspotSync.new.sync(customer) end End

ตรวจสอบให้แน่ใจว่าระบบถูกใช้จริง

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

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

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

ห่อ

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

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

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