ConnectWiz इंटीग्रेशन
आपका स्टैक, जुड़ा हुआ — और उसी से बयान किया गया जो वह सचमुच करता है.
इंटीग्रेशन पेज आमतौर पर लोगो गिनाते हैं. यह पेज व्यवहार गिनाता है: क्या सिंक होता है, किस दिशा में, किसके मालिकाने में, और ईमानदार सीमाएँ कहाँ हैं. क्योंकि "X के साथ जुड़ता है" गहराई का दावा है, कोई स्टिकर नहीं.
कॉमर्स
WooCommerce और WordPress
WooCommerce — दोतरफ़ा, नियम के साथ
एक-क्लिक पेयरिंग, गहरा प्रोडक्ट इंपोर्ट, सचमुच का राइट-बैक — वह भी आपके चुने हुए फ़ील्ड-स्तर के मालिकाने में, हर ऑपरेशन के लिए रिहर्सल मोड और दिखने वाले टकराव लेजर के साथ. पूरी कहानी यहाँ है: कॉमर्स पेज.
पूरा पेजWordPress प्लगइन
आपकी साइट पर चैट विजेट लगाता है और साइन किए हुए SSO token बनाता है — लॉग-इन ग्राहक चैट में पहचान लिए जाते हैं, ऑर्डर समेत, दोबारा रजिस्टर किए बिना.
पूरा पेजGoogle और Meta शॉपिंग फ़ीड
Google के स्कीमा में एक token वाला प्रोडक्ट फ़ीड (Meta Commerce Manager भी वही पढ़ता है) आपके विज्ञापन कैटलॉग सिंक रखता है — रास्ते में कोई ऐप रिव्यू नहीं, हाथ से दोबारा अपलोड नहीं.
Shopify जल्द
बुनियाद असली है — Shopify की ग्राहक पहचान पहले से कॉन्टैक्ट पर जुड़ जाती है, और आज Shopify स्टोर API और webhook से जुड़ते हैं. WooCommerce जैसा नेटिव दोतरफ़ा सिंक रोडमैप पर है, और यह बैज तभी बदलेगा जब वह आएगा, उससे पहले नहीं.
पूरा पेजसपोर्ट और टिकट
Zendesk — बीच रास्ते वाली टीमों के लिए एक पुल
पुश: टिकट बाहर
ConnectWiz की टिकट बातचीतें Zendesk में टिकट बनाती हैं और जवाबों को कमेंट के रूप में दोहराती हैं — ताकि अब भी Zendesk में रह रही टीम को काम बिना पूछे दिखता रहे.
पूरा पेजपुल: एजेंट के जवाब वापस
एक Zendesk ट्रिगर एजेंट के कमेंट वापस ConnectWiz थ्रेड में डाल देता है — एक साझा secret से सुरक्षित, और ऐसे लूप-गार्ड के साथ कि दोनों सिस्टम किसी कमेंट को हमेशा के लिए इधर-उधर न उछालते रहें.
ईमानदार दायरा
यह एक टिकट पुल है — बनाना, जवाब देना, दोनों दिशाएँ चालू-बंद हो सकती हैं — Zendesk का हेल्प-सेंटर, मैक्रो या SLA इंपोर्ट नहीं. टीमें इससे धीरे-धीरे माइग्रेट करती हैं, फिर इसे बंद कर देती हैं.
CRM
Estesoft Stella — आपका CRM, बातचीत से ही दिखता हुआ
हमारे प्रोवाइडर-निरपेक्ष CRM पोर्ट पर पहला प्रोवाइडर: Stella चलाने वाले क्लिनिक अपना CRM रखते हैं और ऊपर से एक बातचीत परत पाते हैं जो उसे सचमुच जानती है.
लाइव कॉन्टेक्स्ट, पहचान से बँधा
Stella से अपॉइंटमेंट, कोटेशन, बकाया, नोट और दस्तावेज़ बातचीत पर ही सामने आते हैं — और AI उन्हें ठीक इसी ग्राहक के लिए पढ़ सकता है, किसी ID का अंदाज़ा लगाकर कभी नहीं.
बुकिंग वापस लिखी जाती हैं
चैट में तय हुआ अपॉइंटमेंट Stella की डायरी में पहुँच जाता है — और जहाँ वेंडर की API कोई ब्योरा नहीं ले जा सकती, वहाँ सिंक चुपचाप गिराने के बजाय बता देता है कि उसने क्या छोड़ा.
जान-बूझकर मना
इलाज के मेडिकल रिकॉर्ड न कभी पढ़े जाते हैं, न दिखाए जाते हैं; वेंडर के अपने lifecycle लेबल कभी ऊपर से नहीं लिखे जाते; और पूरे दोतरफ़ा मिरर का दिखावा नहीं किया जाता — ये सीमाएँ डिज़ाइन के फ़ैसले हैं, लिखकर रखे हुए.
Estesoft Stella — पूरा पेज · कोई और CRM चला रहे हैं? यह पोर्ट डिज़ाइन से ही प्रोवाइडर-निरपेक्ष है — अपना बताएँ. और जब आप पुराना सिस्टम पूरी तरह छोड़ने को तैयार हों, तो नीचे वाला माइग्रेशन इंजन आपकी हिस्ट्री साथ ले आता है.
मार्केटिंग और प्रोवाइडर
अपने प्रोवाइडर ख़ुद लाएँ — घर का उसूल
AI: आपकी कुंजियाँ, 5 प्रोवाइडर
Wiz आपकी अपनी प्रोवाइडर कुंजियों पर चलता है — पाँच AI प्रोवाइडर और दर्जनों मॉडल के साथ. कोई token मार्कअप नहीं, हर काम के लिए मॉडल का चुनाव, और किसी भी वेंडर को छोड़ देने की आज़ादी. पूरी कहानी यहाँ है: AI पेज.
पुश: आपका अपना OneSignal
विज़िटर वेब पुश आपके अपने डोमेन पर आपके अपने पुश ऐप से चलता है — क्योंकि वेब पुश असल में ऐसे ही काम करता है, और इसके उलट दिखावा पहले ही दिन टूट जाता है.
बुकिंग बाहर, व्यस्त समय अंदर
अपॉइंटमेंट Google, Microsoft 365 और Apple/CalDAV कैलेंडर में चले जाते हैं और रद्द होते ही वहाँ से हट जाते हैं; बाहर का व्यस्त समय उपलब्धता में से घट जाता है, इसलिए कोई दरवाज़ा — इंसान हो या AI — पहले से भरा स्लॉट नहीं दे सकता. ब्योरा यहाँ है: बुकिंग पेज.
हर स्रोत की अपनी दिशा
हर कैलेंडर वही भूमिका निभाता है जो आप देते हैं — पढ़ना, लिखना, दोनों, या सिर्फ़ व्यस्तता — ताकि क्लिनिक का साझा कैलेंडर और किसी डॉक्टर का निजी कैलेंडर एक-दूसरे को मिटाए बिना साथ चलें.
विज्ञापन और अनुपालन
बातचीत, विज्ञापन प्लेटफ़ॉर्म और नियामकों के बीच की पाइपलाइन
Meta Conversions API
जीता हुआ सौदा उसी विज्ञापन को वापस ख़बर करता है जिससे चैट शुरू हुई थी — एक purchase इवेंट के रूप में, हर चैनल के हिसाब से ठीक पहचान-मिलान के साथ — और साथ में आपके CRM फ़नल से लीड-क्वालिटी के संकेत. आपका dataset, आपका token, डिफ़ॉल्ट रूप से बंद; कोई भी इवेंट निकलने से पहले चार दरवाज़े (सहमति समेत), और एक सेहत पैनल जो दिखाता है कि क्या भेजा गया और किससे मना हुआ, वजह के साथ.
पूरा पेजİYS (तुर्किये)
Türkiye की व्यापारिक-संचार रजिस्ट्री, जुड़ी हुई: सहमतियाँ दी गई या वापस ली गई के रूप में भेजी जाती हैं, रजिस्ट्री की तरफ़ के opt-out रोज़ वापस खींचे जाते हैं, और क्रेडेंशियल पैनल में सिर्फ़-लिखने वाले रहते हैं. रजिस्ट्री का अनुपालन एक पाइपलाइन की तरह — और उसका मौजूदा डेढ़-तरफ़ा दायरा यहाँ लिखा है: İYS पेज.
पूरा पेजइस हिस्से का ईमानदारी वाला नियम
विज्ञापन और अनुपालन के इंटीग्रेशन सिर्फ़ सहमति के दरवाज़ों के पीछे ही चलते हैं, और मना हुआ हर इवेंट अपनी वजह के साथ लॉग होता है. अगर किसी नंबर का भरोसे लायक़ मिलान नहीं हो पाता, तो अंदाज़ा नहीं लगाया जाता — ग़लत पहचान की कीमत किसी और की निजता चुकाती है.
माइग्रेशन
पुराना CRM छोड़ें. अपनी हिस्ट्री रखें.
सचमुच का एक माइग्रेशन इंजन
जिन स्रोत सिस्टम को हम सपोर्ट करते हैं, उनके लिए: कॉन्टैक्ट, अपॉइंटमेंट हिस्ट्री, कोटेशन, बिक्री ऑर्डर, बकाया और नोट एक कतारबद्ध, रुककर फिर चल सकने वाले इंजन से आते हैं — और यह हमारी टीम के साथ चलता है, क्योंकि CRM बदलने के लिए एक बटन नहीं, एक ऑपरेटर चाहिए.
जो छूटा, वह नाम लेकर बताया जाता है
इंजन मान गढ़ने से मना कर देता है — जिस रिकॉर्ड में करेंसी या तारीख़ नहीं है, वह छोड़ा और गिना जाता है, ताकि "माइग्रेशन पूरा" कभी उन रिकॉर्ड को न छिपाए जो अब भी पुराने सिस्टम में पड़े हैं.
मालिकाना सबसे आख़िर में बदलता है
डेटा का मालिकाना आख़िरी क़दम के तौर पर बदलता है, जब इंपोर्ट ख़ुद को साबित कर चुका होता है — तब तक पुराना सिस्टम ही अंतिम सत्य रहता है, जब तक आप ख़ुद कुछ और तय न करें.
एक ही OpenAPI कॉन्ट्रैक्ट
पूरा प्लेटफ़ॉर्म एक ही OpenAPI 3 दस्तावेज़ में लिखा है — वही कॉन्ट्रैक्ट, जिससे हमारा वेब पैनल और मोबाइल ऐप अपने टाइप बनाते हैं. कोई छिपा endpoint नहीं, दस्तावेज़ का कोई बहाव नहीं.
दायरे वाली Commerce API कुंजियाँ
टेनेंट की जारी की हुई कुंजियाँ, साफ़ scope के साथ — कैटलॉग पढ़ना, ऑर्डर पढ़ना, ऑर्डर लिखना — हमारे कैटलॉग और ऑर्डर इंजन पर आपकी अपनी दुकान या ऐप चलाती हैं.
इनबाउंड webhook, सुरक्षित
कोई भी बाहरी सिस्टम ऑटोमेशन शुरू कर सकता है: हर फ़्लो के webhook ट्रिगर का अपना URL, अपना secret, HMAC जाँच और रीप्ले से बचाव होता है — और payload डेटा होते हैं, निर्देश कभी नहीं.
आउटबाउंड: फ़्लो आपको कॉल करते हैं
REST क़दम आपके सिस्टम को ठीक उन्हीं पलों पर कॉल करता है जो आप कैनवस पर खींचते हैं. सब कुछ सब्सक्राइब कर लेने वाली आम webhook फ़ीड अभी नहीं बनी है — यह यहीं लिखा है, किसी सेल्स कॉल में पता नहीं चलेगा.
गहराई लोगो पर भारी पड़ती है.
जो टुकड़े आप पहले से चला रहे हैं, उन्हें जोड़ें — और चालू करने से पहले ठीक-ठीक जान लें कि हर कनेक्शन क्या करता है.