तुम्ही आधीच वापरत असलेल्या सॉफ्टवेअरशी LumaKol जोडणे

कोणत्याही व्यवसायात CRM ही एकमेव प्रणाली नसते. अकाउंटिंग पॅकेज असते, वेबसाइट असते, तिकिटिंग टूल असते, वेअरहाऊस प्रणाली असते, 2019 मध्ये कोणीतरी बनवलेली आणि आजही सगळे ज्यावर अवलंबून आहेत अशी स्प्रेडशीट असते. यापैकी कोणाशीही बोलू न शकणारा CRM आणखी एक बेट बनतो, आणि बेटांमधला पूल म्हणजे दिवसाच्या शेवटी हाताने ओळी कॉपी करणारी एक व्यक्ती.

LumaKol कडे आता सार्वजनिक API आणि आउटगोइंग वेबहुक आहेत. दोघे मिळून दोन्ही दिशा सांभाळतात: तुम्हाला गरज असेल तेव्हा तुम्ही LumaKol कडून डेटा मागू शकता, आणि काहीतरी घडताक्षणी LumaKol तुम्हाला कळवू शकते. हा लेख संदर्भ-मार्गदर्शक नसून ते कसे बनवले आहेत आणि कोणते वापरायचे हे कसे ठरवावे याबद्दल आहे — एंडपॉइंटची यादी अॅपच्या डेव्हलपर विभागात, तुम्ही की तयार करता त्याच्या शेजारी आहे.

की वर्कस्पेसच्या मालकीच्या असतात, व्यक्तीच्या नव्हे

हा पहिला डिझाइन निर्णय आहे, आणि तोच तुमची एखादी सोमवारची सकाळ वाचवतो. LumaKol मध्ये जारी केलेली API की वर्कस्पेसच्या मालकीची असते. ती तयार करणारा डेव्हलपर कंपनी सोडतो आणि त्याचे खाते निष्क्रिय केले जाते, तेव्हा त्याने बनवलेले इंटिग्रेशन चालूच राहते: की तिच्या निर्मात्यासोबत संपुष्टात येण्याऐवजी वर्कस्पेस मालकाच्या वतीने काम करू लागते.

वैयक्तिक लॉगिनवर बनवलेले इंटिग्रेशन चालवलेल्या कोणालाही हे का महत्त्वाचे आहे ते माहीत आहे. अशी इंटिग्रेशन ती व्यक्ती गेल्यानंतर आठवड्यांनी, कोणताही आवाज न करता बंद पडतात, आणि अडचणीचे पहिले लक्षण म्हणजे एखाद्या रिपोर्टमधील भगदाड.

स्कोप

की ती काय करू शकते याच्या स्पष्ट यादीसह जारी केली जाते, आणि त्याव्यतिरिक्त काहीही नाही:

प्रत्येक इंटिग्रेशनला काम भागेल इतक्या सर्वात लहान स्कोपसह स्वतःची की द्या. फक्त चार्ट काढणाऱ्या डॅशबोर्डला leads:read आणि calls:read मिळतात, आणि की चुकीच्या ठिकाणी पोहोचली तरी तो कोणतेही नुकसान करू शकत नाही. वेबसाइट फॉर्म हँडलरला leads:write मिळतो आणि तो तुमचा कॉल इतिहास वाचू शकत नाही. की तयार करताना या सवयीला काहीच किंमत लागत नाही, आणि काहीतरी बिघडते त्या दिवशी तिची किंमत खूप मोठी ठरते.

साठवण आणि रद्द करणे

की फक्त एकदाच, ती तयार होत असतानाच दाखवली जाते, आणि पुन्हा कधीच नाही. LumaKol तिचा एकमार्गी हॅश साठवते, त्यामुळे की डेटाबेसमधून कोणालाही — आम्हालाही — परत वाचता येत नाही. ती हरवली तर तुम्ही नवीन जारी करता; पुनर्प्राप्ती नाही, आणि ते जाणीवपूर्वक तसे आहे.

रद्द करणे तात्काळ होते. रद्द करा दाबा, आणि त्या कीने केलेली पुढची विनंती नाकारली जाते. कोणताही अतिरिक्त कालावधी नाही आणि बदल पसरण्याची वाट पाहावी लागत नाही — लॅपटॉप हरवतो किंवा कंत्राटदाराचे काम संपते तेव्हा तुम्हाला हेच हवे असते.

की वर्कस्पेसच्या स्थितीचाही आदर करतात. वर्कस्पेस निलंबित असेल, तर तिच्या की पूर्णपणे काम करणे थांबवतात. ती फक्त-वाचनीय असेल — संपलेली चाचणी, रद्द केलेला प्लॅन — तर की GET विनंत्या पूर्ण करत राहतात पण लेखन नाकारतात, अगदी अॅपप्रमाणेच. इंटिग्रेशन कधीच खात्याच्या स्थितीला बगल देणारा मागचा दरवाजा बनू शकत नाही.

API वर भडिमार न करता डेटा वाचणे

बेस URL: https://api.lumakol.com/api/v1. याद्या पान क्रमांकांऐवजी कर्सरने पेजिनेट केल्या जातात, आणि हे जितके वाटते त्यापेक्षा जास्त महत्त्वाचे आहे.

सिंक सुरू असताना पान क्रमांक बिघडतात. तुम्ही पहिले पान आणता, कोणीतरी लीड अपडेट करतो, क्रम सरकतो, आणि दुसरे पान आता अशा रेकॉर्डनंतर सुरू होते जो तुम्ही कधी पाहिलाच नाही. काही हजार लीड्सच्या रात्रीच्या सिंकमध्ये याचा अर्थ दररोज रात्री काही रेकॉर्ड गहाळ होणे, आणि असे घडल्याचे कोणतेही लक्षण नसणे. कर्सर क्रमातील एका निश्चित स्थानाकडे निर्देश करतो, त्यामुळे लोक काम करत असतानाही संपूर्ण संच पानोपानी पाहताना प्रत्येक रेकॉर्ड तुम्हाला अगदी एकदाच मिळतो.

यादीच्या प्रतिसादात ओळी, पुढचा कर्सर, आणि आणखी शिल्लक आहे की नाही हे सांगणारा फ्लॅग असतो. लूप असा आहे: विनंती, प्रक्रिया, कर्सर परत पाठवा, फ्लॅग false होईपर्यंत पुन्हा करा. त्याला updated-since फिल्टरची जोड द्या आणि इन्क्रिमेंटल सिंक सोपे होते — तुमच्या शेवटच्या यशस्वी रननंतर बदललेले सर्व काही मागा, पानोपानी पाहा, टाइमस्टॅम्प साठवा, थांबा. टप्पा, मालक, स्रोत, टॅग आणि मुक्त मजकुरासाठी फिल्टर आहेत, तसेच तुमच्या स्वतःच्या बाह्य ओळखकर्त्याने शोधण्याची सोय आहे, त्यामुळे मॅपिंग टेबल न ठेवता तुम्ही LumaKol च्या लीड्स तुमच्या प्रणालीतील रेकॉर्डशी जुळवू शकता.

वेबहुक: प्रतिसाद द्यावा असे सहा इव्हेंट

जे काही तत्परतेने घडायला हवे त्यासाठी पोलिंग हे चुकीचे साधन आहे. लीड एखाद्या विशिष्ट टप्प्यावर पोहोचल्यावर मेसेज जावा असे तुम्हाला वाटत असेल, तर दर पंधरा मिनिटांनी तपासणे म्हणजे मेसेज पंधरा मिनिटांपर्यंत उशिरा जातो आणि प्रत्येक उपयुक्त विनंतीसाठी तुम्ही शहाण्णव निरर्थक विनंत्या केलेल्या असतात.

तुम्ही तुमचा एखादा HTTPS एंडपॉइंट या सहा इव्हेंटपैकी कोणत्याही संयोजनासाठी सबस्क्राइब करू शकता:

• lead.created — कोणत्याही स्रोतातून वर्कस्पेसमध्ये लीड आली.
• lead.updated — लीडवरील एखादे फील्ड बदलले.
• lead.stage_changed — लीड पाइपलाइनमध्ये पुढे सरकली. बहुतेक व्यावसायिक लॉजिक याच इव्हेंटवर अवलंबून असते.
• lead.assigned — लीडला नवीन मालक मिळाला.
• call.logged — लीडवर निकालासह कॉल नोंदवला गेला.
• follow_up.due — वचन दिलेल्या कॉलबॅकची वेळ आली.

गोष्ट घडताक्षणी, बदलाच्याच श्वासात इव्हेंट रांगेत टाकले जातात, त्यामुळे कृती आणि सूचना यांच्या दरम्यान झालेल्या रीस्टार्टमुळे इव्हेंट हरवू शकत नाही. अॅपच्या दृष्टीने ते पाठवून विसरून जाण्यासारखेही आहेत: बंद असलेला किंवा संथ वेबहुक एंडपॉइंट एजंटच्या कॉल नोंदवण्याला कधीच उशीर करू शकत नाही किंवा अपयशी ठरवू शकत नाही.

डिलिव्हरी खरोखर आमच्याकडूनच आली आहे याची पडताळणी

तुमचा एंडपॉइंट सार्वजनिक इंटरनेटवरील एक URL आहे, आणि तो कळलेला कोणीही त्यावर पोस्ट करू शकतो. म्हणून प्रत्येक डिलिव्हरीसोबत इव्हेंट आणि डिलिव्हरी ओळखणारे हेडर, एक टाइमस्टॅम्प, आणि फक्त तुमच्यासोबत शेअर केलेल्या सिक्रेटचा वापर करून टाइमस्टॅम्प व बॉडीवर मोजलेली HMAC-SHA256 स्वाक्षरी असते.

पेलोडमधील एकाही फील्डवर विश्वास ठेवण्यापूर्वी तुमच्या रिसीव्हरने मूळ रिक्वेस्ट बॉडीवरून ती स्वाक्षरी पुन्हा मोजून तुलना करायला हवी. व्यवहारात दोन तपशील महत्त्वाचे आहेत: पार्स केलेल्या JSON ची पुन्हा सीरियलाइज केलेली आवृत्ती नव्हे, तर मूळ बॉडी वापरा, कारण एका रिकाम्या जागेच्या फरकानेही स्वाक्षरी बदलते; आणि साध्या समानता-तपासणीऐवजी constant-time तुलना वापरा. सिक्रेट मागणीनुसार पुन्हा दाखवता येते — त्यामुळे वेबहुक न हटवता रिसीव्हर पुन्हा तयार करता येतो — आणि गरज पडल्यास बदलता येते.

तुमचा एंडपॉइंट बंद असेल तेव्हा

अयशस्वी डिलिव्हरी साधारण अर्ध्या दिवसाच्या, सुरुवातीला जास्त वारंवारता असलेल्या वेळापत्रकानुसार पुन्हा प्रयत्न केल्या जातात: पहिले प्रयत्न काही मिनिटांतच होतात, मग अंतर वाढत तासांपर्यंत जाते. डिप्लॉयसाठी बंद असलेला रिसीव्हर काहीच गमावत नाही. दिवसभर बंद असलेल्या रिसीव्हरचा नाद सोडला जातो, कारण तोपर्यंत इव्हेंट शिळे झालेले असतात आणि मर्यादेशिवाय वाढणारी रांग कोणाच्याच उपयोगाची नसते.

अलीकडील डिलिव्हरी प्रयत्न अॅपमध्ये त्यांची स्थिती, प्रयत्नांची संख्या आणि तुमच्या एंडपॉइंटने दिलेल्या प्रतिसादासह दिसतात, त्यामुळे नेहमीचा “चूक त्यांची की आमची?” हा वाद यादीवर दोन मिनिटांची नजर टाकण्यात बदलतो. चाचणी डिलिव्हरीचे बटणही आहे, त्यामुळे रिसीव्हरवर अवलंबून राहण्यापूर्वी तो काम करतो हे तुम्ही सिद्ध करू शकता. वेबहुक URL HTTPS असायला हवेत आणि सार्वजनिक पत्त्यावर रिझॉल्व्ह व्हायला हवेत — खाजगी किंवा अंतर्गत रेंजकडे निर्देश करणारा URL सेव्ह करतानाच नाकारला जातो आणि प्रत्येक डिलिव्हरीपूर्वी पुन्हा तपासला जातो.

कोड न लिहिता ते जोडणे

Zapier साठी LumaKol अॅप तयार आहे आणि Zapier च्या पुनरावलोकनाची वाट पाहत आहे; ते त्यांच्या डिरेक्टरीत येईपर्यंत, आणि Make, n8n किंवा Pabbly Connect वर, मार्ग म्हणजे मॅन्युअल कनेक्शन. त्यासाठी तुम्हाला अॅपची गरज नाही. या प्रत्येक प्लॅटफॉर्मवर सर्वसाधारण वेबहुक ट्रिगर आणि सर्वसाधारण HTTP अॅक्शन असते, आणि या दोघांच्या मदतीने समर्पित अॅप जे देईल त्यातील बहुतेक तुम्ही बनवू शकता.

1. ऑटोमेशन प्लॅटफॉर्ममध्ये, त्याच्या इनकमिंग वेबहुक ट्रिगरने सुरू होणारे नवीन सिनारिओ तयार करा — “Webhooks by Zapier”, Make मधील “Custom webhook”, n8n मधील Webhook नोड, Pabbly मधील “Catch Hook”. त्याने दिलेला URL कॉपी करा.
2. LumaKol मध्ये, त्या URL कडे निर्देश करणारा वेबहुक जोडा आणि तुम्हाला हव्या असलेल्या इव्हेंटसाठी तो सबस्क्राइब करा. चाचणी डिलिव्हरी पाठवा, म्हणजे प्लॅटफॉर्मला पेलोडचे स्वरूप दिसेल आणि तो फील्ड मॅपिंग तयार करू शकेल.
3. तुमची अॅक्शन पायरी जोडा: Google Sheets मधील एक ओळ, Slack मधील मेसेज, तुमच्या अकाउंटिंग प्रणालीतील रेकॉर्ड, व्यवस्थापकाला ईमेल.
4. LumaKol मध्ये परत लिहिण्यासाठी, प्लॅटफॉर्मची HTTP request अॅक्शन API वर वापरा, authorisation हेडरमध्ये तुमच्या एका कीसह — लीड तयार करणे, टप्पा अपडेट करणे किंवा टीप जोडणे. तुम्हाला फक्त नवीन लीड्स पाठवायच्या असतील, तर “वेबसाइट किंवा इतर अॅप” प्रकारचा लीड स्रोत (सेटअप → लीड स्रोत) तुम्हाला खाजगी वेबहुक URL देतो ज्याला कीची गरज नसते आणि जो त्या स्रोताचा मालक, टप्पा आणि टॅग प्रत्येक लीडला लागू करतो.
5. सिनारिओ चालू करा आणि त्यावर अवलंबून राहण्यापूर्वी जाणूनबुजून तो बिघडवून पाहा: त्याला चुकीच्या URL कडे वळवा आणि डिलिव्हरी यादीत अपयश दिसते ते पाहा, म्हणजे खरोखर अडचण आल्यावर ती कशी दिसते हे तुम्हाला माहीत असेल.

Zapier अॅप सूचीबद्ध झाल्यावर तिथे काही क्लिक वाचतील. सर्वसाधारण मार्ग आजच प्रत्येक प्लॅटफॉर्मवर काम करतो आणि, तो साधा स्वाक्षरी केलेला वेबहुक आणि साधा REST कॉल असल्याने, तुम्ही नंतर कोणत्याही ऑटोमेशन प्लॅटफॉर्मवर गेलात तरी काम करत राहतो.