मुख्य सामग्री पर जाएँ
रियल एस्टेट और आतिथ्य का डिजिटलीकरण· 7 में से भाग 4

शिकायत से समापन तक: प्रॉपर्टी मेंटेनेंस अनुरोधों का प्रबंधन

संक्षिप्त जवाब

रसोई में एक छोटा-सा रिसाव शाम को किसी कर्मचारी के WhatsApp पर एक फ़ोटो के रूप में आता है। कर्मचारी व्यस्त है, इसलिए वह इंतज़ार करता है, फिर भुला दिया जाता है, और दो हफ़्ते बाद फिर सामने आता है जब किरायेदार गुस्से में फ़ोन करता है और सिंक के नीचे की लकड़ी पहले ही फूल चुकी होती है। किसी ने लापरवाही नहीं की, लेकिन उस शिकायत के रहने की कोई जगह नहीं थी। रियल एस्टेट और हॉस्पिटैलिटी का डिजिटलीकरण का चौथा भाग एक मेंटेनेंस अनुरोध को निजी चैट के एक संदेश से बदलकर एक छोटे वर्क ऑर्डर में बदलता है, जिसमें स्रोत, यूनिट, प्राथमिकता, ज़िम्मेदार व्यक्ति, लागत और दर्ज किया गया समापन होता है।

Origami टीम

संपादकीय टीम · · 7 मिनट का पाठ

WhatsApp पर साझा करें
हम जो प्रकाशित करते हैं वह आपको पसंद है? Google में Origami को अपना पसंदीदा स्रोत बनाइए।Add as a preferred source on Google
शिकायत से समापन तक: प्रॉपर्टी मेंटेनेंस अनुरोधों का प्रबंधन
रियल एस्टेट और आतिथ्य का डिजिटलीकरण · 7 में से भाग 4
इस लेख में
  1. जहाँ जवाबदेही खत्म हो जाती है
  2. एक शिकायत एक छोटा वर्क ऑर्डर है
  3. प्राथमिकता एक लिखित नियम है, एहसास नहीं
  4. असाइनमेंट से समापन तक
  5. दस्तावेज़ीकरण दोनों पक्षों की रक्षा करता है
  6. Origami का नज़रिया
  7. इस हफ़्ते आप क्या कर सकते हैं
  8. आगे क्या
  9. स्रोत

तीसरे भाग ने पैसे के चक्र को याददाश्त से निकालकर तारीखों, ज़िम्मेदार लोगों और तय रास्तों वाली प्रक्रिया में पहुँचाया। अब हम उस दूसरे चक्र की ओर बढ़ते हैं जो किसी भी प्रॉपर्टी पोर्टफ़ोलियो में रोज़ चलता है, और जो अकेला ऐसा चक्र है जिसे आप नहीं, आपका किरायेदार शुरू करता है: मेंटेनेंस।

दोनों चक्रों में अंतर यह है कि पैसे की तारीखें पहले से पता होती हैं, जबकि मेंटेनेंस बिना समय लिए आ जाता है। शुक्रवार को एयर कंडीशनर बंद हो जाता है, रात में रिसाव दिखता है, छह परिवारों वाली इमारत में लिफ़्ट रुक जाती है। यही अनिश्चितता ठीक वह कारण है जिसकी वजह से मेंटेनेंस को एक तय प्रक्रिया की ज़रूरत होती है, क्योंकि जो कुछ भी अचानक आता है और उसे कोई तैयार रास्ता नहीं मिलता, वह सबसे आसान उपलब्ध जगह पर चला जाता है: किसी कर्मचारी के फ़ोन की निजी चैट।

जहाँ जवाबदेही खत्म हो जाती है

मुझे मेरे WhatsApp पर फ़ोटो भेज दीजिए, यह किरायेदार को तेज़ सेवा जैसा लगता है। व्यवहार में यही वह बिंदु है जहाँ जवाबदेही भाप बनकर उड़ जाती है। जब कोई शिकायत निजी चैट में रहती है, तो एक साथ पाँच चीज़ें होती हैं:

  • शिकायत दफ़्तर की नहीं, एक व्यक्ति की हो जाती है। अगर वह कर्मचारी यात्रा पर जाए, नौकरी छोड़ दे या फ़ोन बदल ले, तो जो कुछ अभी तक नहीं हुआ वह सब उसके साथ चला जाता है, और किसी को यह भी पता नहीं होता कि क्या खो गया।
  • किसी को नहीं पता कि इस समय कितनी शिकायतें खुली हैं। आज कितने अनुरोध सक्रिय हैं, इस सीधे सवाल का कोई जवाब नहीं होता, क्योंकि वे ऐसी बातचीतों में बिखरे होते हैं जिन्हें कोई एक सूची इकट्ठा नहीं करती।
  • प्राथमिकता उसे मिलती है जिसने सबसे ज़्यादा दबाव डाला। पाँच संदेश भेजने वाले किरायेदार का काम एक ही संदेश भेजने वाले से पहले होता है, भले ही दूसरी शिकायत इमारत के लिए ज़्यादा खतरनाक हो।
  • लागत गायब हो जाती है। तकनीशियन काम करता है और उसे नकद या ट्रांसफ़र से भुगतान होता है, और वह रकम कभी उस यूनिट से नहीं जुड़ती जिस पर वह खर्च हुई। साल खत्म होता है और आप नहीं बता सकते कि किस यूनिट ने आपको जितना दिया उससे ज़्यादा खर्च कराया।
  • कोई समापन नहीं होता। शिकायत तब खत्म होती है जब किरायेदार पूछना बंद कर देता है, न कि तब जब वह पुष्टि करता है कि खराबी वास्तव में ठीक हो गई। इन दोनों के बीच का अंतर एक महीने बाद तब दिखता है जब वही खराबी लौट आती है।

इन पाँचों में से कोई भी लापरवाही की समस्या नहीं है। कर्मचारी मदद करना चाहता है और तकनीशियन काम करता है। समस्या यह है कि शिकायत कभी यूनिट के सामने दर्ज ही नहीं हुई, इसलिए वह किसी की याद में एक घटना बनकर रह गई — और लोगों की याददाश्त उस संपत्ति का रिकॉर्ड नहीं है जिसके आप मालिक हैं या जिसका आप प्रबंधन करते हैं।

एक शिकायत एक छोटा वर्क ऑर्डर है

मेंटेनेंस को नियंत्रण में लाने का सबसे आसान तरीका है अनुरोध को एक संदेश की तरह देखना बंद करना और उसे एक छोटे वर्क ऑर्डर की तरह देखना शुरू करना। और वर्क ऑर्डर तभी वर्क ऑर्डर है जब उसमें छह तत्व हों:

  • स्रोत। किसने शिकायत की, कब और किस चैनल से। किरायेदार की शिकायत, किसी नियमित निरीक्षण में मिली टिप्पणी या किसी दूसरे काम से इमारत में आए तकनीशियन से अलग होती है, और स्रोत दर्ज करना ही वह चीज़ है जो बाद में यूनिट के इतिहास को पढ़ने लायक बनाती है।
  • यूनिट। विशिष्ट यूनिट और इमारत, किरायेदार का नाम नहीं — क्योंकि जिस संपत्ति पर खराबी बार-बार होती है वह यूनिट है, और किरायेदार उसके ऊपर बदलते रहते हैं।
  • विवरण और सबूत। एक छोटा टेक्स्ट और एक या अधिक फ़ोटो। शिकायत के समय ली गई फ़ोटो ही बाद में यह सवाल सुलझाती है कि खराबी किरायेदार के आने से पहले थी या बाद में।
  • प्राथमिकता। एक बंद सूची से, जो उसी पल लिए गए फ़ैसले से नहीं बल्कि एक लिखित नियम से तय होती है।
  • ज़िम्मेदार व्यक्ति और लक्ष्य तारीख। एक नामित व्यक्ति या ठेकेदार, और एक अपेक्षित तारीख जो किरायेदार को बताई जाती है।
  • लागत और समापन। यूनिट पर डाली गई वास्तविक रकम, और किरायेदार की यह पुष्टि कि खराबी हल हो गई।

ये छह अतिरिक्त नौकरशाही नहीं हैं। हर एक ऐसे सवाल का जवाब देता है जिसका जवाब आपको बाद में चाहिए होगा: इसे कौन देख रहा है, कौन-सी संपत्ति खराब हुई, क्या शिकायत दर्ज है, इसे उससे पहले क्यों किया गया, काम किसने किया, कितनी लागत आई, और क्या यह वास्तव में खत्म हुआ।

प्राथमिकता एक लिखित नियम है, एहसास नहीं

किसी दफ़्तर का सबसे ज़्यादा समय इस बात पर आंतरिक मोलभाव में जाता है कि पहले क्या किया जाए। इसका हल रोज़ की बैठक नहीं, बल्कि एक बार लिखा गया और टीम के साथ साझा किया गया नियम है। एक व्यावहारिक नियम शिकायतों को क्रम से तीन सवालों के आधार पर वर्गीकृत करता है: क्या सुरक्षा का कोई जोखिम है, क्या यह यूनिट के उपयोग को रोकता है, और क्या देरी होने पर यह बिगड़ता है।

  • अत्यावश्यक। जो कुछ भी सुरक्षा को छूता है, किसी ज़रूरी सुविधा को बंद कर देता है, या हर घंटे के साथ नुकसान बढ़ाता है: पानी का रिसाव, बिजली की खराबी, रुकी हुई लिफ़्ट, ऐसा दरवाज़ा जिसमें ताला नहीं लगता। नुकसान रोकने के लिए तुरंत जवाब दिया जाता है, भले ही अस्थायी रूप से।
  • महत्वपूर्ण। जो कुछ भी यूनिट के किसी हिस्से को बेकार कर देता है पर तेज़ी से नहीं फैलता: एक कमरे का एयर कंडीशनर, वॉटर हीटर, रसोई का कोई उपकरण। इसे एक नज़दीकी तारीख मिलती है, जो किरायेदार को बताई जाती है।
  • नियमित। सुधार, बाहरी रूप और ऐसी कमियाँ जो रहने लायक होने पर असर नहीं डालतीं। इन्हें इकट्ठा करके एक निर्धारित विज़िट में एक साथ किया जाता है — जो अपने आप में ही उसी इमारत तक तकनीशियन के बार-बार के चक्कर बचाता है।

इस वर्गीकरण में जो मायने रखता है वह इसकी सटीकता नहीं, बल्कि इसकी निरंतरता है। जब नियम लिखा होता है, तो कर्मचारी किरायेदार को समझा सकता है कि उसका अनुरोध आज नहीं, कल क्यों होगा, और मालिक एक महीने बाद उस फ़ैसले की समीक्षा कर सकता है। जो नियम कभी लिखा नहीं जाता, वह अपने-आप एक ही नियम बन जाता है: जो सबसे ज़ोर से चिल्लाए।

असाइनमेंट से समापन तक

वर्गीकरण के बाद अमल का चक्र शुरू होता है — चार कदम, और हर एक लिखित निशान छोड़ता है:

  • असाइनमेंट। अनुरोध विवरण, फ़ोटो और एक तारीख के साथ किसी नामित तकनीशियन या ठेकेदार को जाता है। बिना स्पष्ट नाम के दर्ज किया गया असाइनमेंट फिर से सबकी ज़िम्मेदारी बन जाता है, यानी किसी की नहीं।
  • किरायेदार के साथ तालमेल। तय किया गया और पहले से बताया गया प्रवेश समय। तकनीशियन के बिना काम किए लौटने का सबसे आम कारण यह है कि वह पहुँचता है और यूनिट में कोई नहीं मिलता, और यह बिना नतीजे की भुगतान वाली विज़िट है।
  • अमल और दस्तावेज़ीकरण। वास्तव में क्या किया गया, कौन-से पुर्ज़े लगे, काम के बाद की फ़ोटो और रकम। वह रकम सामान्य खर्चों पर नहीं, यूनिट पर डाली जाती है, और यही जुड़ाव बाद में आपको प्रति यूनिट मेंटेनेंस लागत जानने देता है।
  • किरायेदार की पुष्टि के साथ समापन। दफ़्तर अनुरोध को अकेले बंद नहीं करता; वह शिकायत करने वाले की इस पुष्टि पर बंद करता है कि समस्या खत्म हो गई। अगर उचित समय के भीतर कोई पुष्टि नहीं आती, तो इस तथ्य को स्पष्ट रूप से दर्ज करते हुए इसे बंद किया जाता है।

एक पाँचवाँ कदम है जिसे लगभग सभी छोड़ देते हैं: वारंटी और दोहराव। जब उसी यूनिट में थोड़े समय के भीतर वही खराबी लौटती है, तो समस्या खराबी नहीं, बल्कि मरम्मत या उसे करने वाला व्यक्ति है। नए अनुरोध को उसी यूनिट के पिछले अनुरोध से जोड़ना ही वह चीज़ है जो इस पैटर्न को दिखाती है, बजाय इसके कि आप उसके लिए दो बार भुगतान करें।

दस्तावेज़ीकरण दोनों पक्षों की रक्षा करता है

कुछ मालिक मानते हैं कि मेंटेनेंस का दस्तावेज़ीकरण एक ऐसी प्रक्रिया है जो मालिक की कीमत पर किरायेदार की रक्षा करती है। असल में यह दोनों की रक्षा करता है, अलग-अलग तरीकों से।

मालिक या दफ़्तर को एक ऐसा रिकॉर्ड मिलता है जो साबित करता है कि उन्होंने जवाब दिया, कब और किस लागत पर — ठीक वही जो दायित्वों को लेकर किसी भी विवाद में, या अनुबंध के अंत में सिक्योरिटी डिपॉज़िट से कटौती करते समय चाहिए होता है। उन्हें संपत्ति का तकनीकी इतिहास भी मिलता है: यह लिफ़्ट कितनी बार खराब हुई, किस ठेकेदार का काम एक महीने बाद फिर लौट आता है, और कौन-सी यूनिट अपनी ही आय का जितना दिखता है उससे ज़्यादा हिस्सा खा जाती है।

किरायेदार को कुछ सरल मिलता है: यह जानना कि शिकायत दर्ज हो गई, उसका एक नंबर और तारीख है, और उसे ज़िंदा रखने के लिए हर दो दिन में दोबारा भेजने की ज़रूरत नहीं है। यह बात सीधे पिछले भाग के नवीनीकरण से जुड़ती है, क्योंकि जो चीज़ किसी अच्छे किरायेदार को नवीनीकरण न करने की ओर धकेलती है वह आमतौर पर कीमत नहीं, बल्कि यह एहसास होता है कि उसके अनुरोध गायब हो जाते हैं।

शॉर्ट-स्टे हॉस्पिटैलिटी यूनिट्स में असर और भी तीखा होता है, क्योंकि तैयार यूनिट और छोटी-सी अनसुलझी खराबी वाली यूनिट के बीच का अंतर एक सार्वजनिक रेटिंग में दिखता है जिसे हर भावी मेहमान पढ़ता है। वहाँ तैयारी अच्छी नीयत नहीं, बल्कि एक चेकलिस्ट का नतीजा है जो हर दो मेहमानों के बीच चलाई जाती है और किसी भी दूसरे मेंटेनेंस अनुरोध की तरह दर्ज की जाती है।

Origami का नज़रिया

रियल एस्टेट और होटल हमारे विशेषज्ञता वाले क्षेत्रों में से एक है, और हम मेंटेनेंस अनुरोध को किसी कर्मचारी को आए संदेश की तरह नहीं, बल्कि एक यूनिट से जुड़े वर्क ऑर्डर की तरह देखते हैं। व्यावहारिक अंतर यह है कि वर्क ऑर्डर की एक मापने योग्य स्थिति होती है, एक प्रतिक्रिया समय जिसकी आप तुलना कर सकते हैं, और एक लागत जो किसी विशिष्ट संपत्ति पर जमा होती है — जबकि संदेश अपने पीछे एक धारणा के सिवा कुछ नहीं छोड़ता।

हम जो क्रम सुझाते हैं: निजी नंबरों के बजाय किरायेदारों के लिए एक घोषित इनटेक चैनल खोलें, फिर हर शिकायत को आते ही उसकी यूनिट से जोड़ें, फिर प्राथमिकता का नियम लिखें और उसे अपनाएँ, फिर किरायेदार की पुष्टि और लागत के साथ चक्र को बंद करें। हम यह क्रम रियल एस्टेट और होटल परियोजनाओं में लागू करते हैं, क्योंकि इनटेक के नियंत्रण में आने से पहले प्रतिक्रिया समय या प्रति यूनिट लागत मापने से ऐसे आँकड़े मिलते हैं जो यह नहीं दिखाते कि वास्तव में क्या हो रहा है।

इस हफ़्ते आप क्या कर सकते हैं

इन कदमों के लिए किसी नए टूल की ज़रूरत नहीं है, और ये किसी भी खरीद के फ़ैसले से पहले समस्या का आकार बताते हैं:

  • आज ही सभी खुली शिकायतों को एक शीट पर इकट्ठा करें टीम के सभी फ़ोनों और WhatsApp ग्रुप्स से। सिर्फ़ गिनती ही आपको चौंका देगी, और यह इस क्षेत्र में आपके पास आया पहला आँकड़ा होगा।
  • हर शिकायत के सामने यूनिट और आने की तारीख लिखें और गिनें कि कितने दिन बीत चुके हैं। दो हफ़्ते से पुरानी हर चीज़ आपकी तत्काल प्राथमिकता सूची है।
  • एक इनटेक चैनल तय करें और हर किरायेदार को इसके बारे में लिखित रूप से बताएँ, फिर निजी नंबरों पर शिकायतें लेना बंद करें।
  • प्राथमिकता का नियम एक पेज पर लिखें तीन स्तरों और हर एक के उदाहरणों के साथ, और इसे टीम में बिना किसी अपवाद के अपनाएँ।
  • दो आँकड़े निकालें: पिछले दो महीनों में शिकायत से समापन तक के औसत दिन, और उसी यूनिट में कितनी खराबियाँ दोबारा हुईं। यही वह आधार रेखा है जिससे आप बाद के हर सुधार को मापेंगे।

आगे क्या

हमने स्थिति को, फिर पैसे को, फिर मेंटेनेंस को व्यवस्थित किया। अगला भाग उस परत तक जाता है जिस पर विवाद शुरू होते ही तीनों टिके होते हैं: दस्तावेज़। अनुबंध और उसके परिशिष्ट, किरायेदार की पहचान, फ़ोटो के साथ हैंडओवर रिकॉर्ड, भुगतान की रसीदें और मेंटेनेंस रिपोर्ट — किसी कर्मचारी के नाम वाले फ़ोल्डर से नहीं, बल्कि यूनिट से जुड़े हुए — और किसी विवाद में सबूत के तौर पर वास्तव में क्या चाहिए।

स्रोत

  • #टेक्नोलॉजी का पूरा लाभ उठाएँ
  • #रियल एस्टेट और हॉस्पिटैलिटी
  • #मेंटेनेंस प्रबंधन
  • #ऑपरेटिंग सिस्टम

सामान्य प्रश्न

मेंटेनेंस शिकायतें लेने के लिए किसी कर्मचारी का फ़ोन गलत जगह क्यों है?

क्योंकि शिकायत दफ़्तर की नहीं, एक व्यक्ति की संपत्ति बन जाती है। अगर वह कर्मचारी यात्रा पर जाए या नौकरी छोड़ दे, तो जो कुछ अभी तक नहीं हुआ वह सब उसके साथ चला जाता है, आप यह नहीं बता सकते कि इस समय कितने अनुरोध खुले हैं, और प्राथमिकता उसे मिलती है जिसने सबसे ज़्यादा दबाव डाला, न कि उसे जिसकी शिकायत ज़्यादा गंभीर है। विकल्प है सभी किरायेदारों के लिए घोषित एक ही इनटेक चैनल, जहाँ हर शिकायत आते ही उसकी यूनिट के सामने दर्ज की जाती है।

हर मेंटेनेंस अनुरोध में कौन-से तत्व होने चाहिए?

छह: स्रोत और उसका समय, किरायेदार के नाम के बजाय विशिष्ट यूनिट, ऐसी फ़ोटो के साथ विवरण जो शिकायत के समय की स्थिति साबित करे, एक बंद सूची से प्राथमिकता, अपेक्षित तारीख के साथ एक ज़िम्मेदार व्यक्ति, और फिर यूनिट पर डाली गई वास्तविक लागत और शिकायत करने वाले द्वारा पुष्टि किया गया समापन। हर तत्व एक ऐसे सवाल का जवाब देता है जिसकी ज़रूरत आपको बाद में, किसी समीक्षा या विवाद में पड़ेगी।

रोज़ की बहस के बिना प्राथमिकता कैसे तय करूँ?

एक बार लिखे गए नियम से, जो हर शिकायत को तीन सवालों से वर्गीकृत करता है: क्या सुरक्षा का कोई जोखिम है, क्या यह यूनिट के उपयोग को रोकता है, और क्या देरी होने पर यह बिगड़ता है। जो कुछ भी सुरक्षा को छूता है या नुकसान को बढ़ाता है वह अत्यावश्यक है, जो कुछ भी यूनिट के किसी हिस्से को बेकार कर देता है वह महत्वपूर्ण है और उसकी एक नज़दीकी घोषित तारीख होती है, और बाकी सब नियमित है जिसे एक निर्धारित विज़िट में एक साथ निपटाया जाता है। मूल्य नियम की सटीकता में नहीं, उसकी निरंतरता में है, क्योंकि उसके बिना प्राथमिकता अपने-आप उसी के पास चली जाती है जो सबसे ज़ोर से चिल्लाता है।

मेंटेनेंस अनुरोध को कब बंद माना जाता है?

जब शिकायत करने वाला व्यक्ति पुष्टि करे कि समस्या वास्तव में हल हो गई है, न कि जब वह पूछना बंद कर दे। अगर उचित समय के भीतर कोई पुष्टि नहीं आती, तो इसे बंद करें और यह बात स्पष्ट रूप से दर्ज करें। समापन के बाद भी एक चीज़ पर नज़र रखना ज़रूरी है: उसी यूनिट में थोड़े समय के भीतर वही खराबी दोबारा होना, क्योंकि यह संपत्ति में नहीं, बल्कि मरम्मत या ठेकेदार में खामी की ओर इशारा करता है।

स्टोर, रियल एस्टेट और सेवाओं के लिए सॉफ़्टवेयर

सऊदी पेमेंट गेटवे वाले ऑनलाइन स्टोर, और प्रॉपर्टी व बुकिंग सिस्टम, आपके काम के तरीक़े के हिसाब से।

व्यापार और सेवा समाधान

न्यूज़लेटर

नए लेख और शृंखलाएँ, सीधे आपके इनबॉक्स में।

Google पर Origami को फ़ॉलो करें

Origami को अपना पसंदीदा स्रोत बनाइए, तो हमारे लेख आपको Google Search और प्रमुख ख़बरों में सबसे पहले दिखेंगे।

Add as a preferred source on Google