सपोर्ट जांचें मूलतः अनुसंधान-आधारित समस्याएँ होती हैं, इसलिए ग्राहक समस्याओं का जवाब देने में सबसे धीमा हिस्सा हमेशा सही संदर्भ इकट्ठा करना रहा है। कोड, लॉग्स, टीम के ज्ञान और पिछली बातचीत को एक ही Cursor सत्र में समेटकर, हमने अपने अधिकांश काम में उस रुकावट को हटा दिया है।

आज, Cursor के 75% से अधिक सपोर्ट इंटरैक्शन Cursor के भीतर ही चलते हैं, जिससे सपोर्ट इंजीनियरों का थ्रूपुट 5–10 गुना बढ़ गया है। इसके परिणामस्वरूप, सिर्फ एक साल पहले की तुलना में सपोर्ट इंजीनियर अब कहीं अधिक कर पा रहे हैं।

#कोडबेस से शुरुआत

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

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

#MCP के साथ सपोर्ट स्रोतों का एकीकरण

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

MCP सर्वर हमें इनका एकीकरण करने की अनुमति देते हैं:

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

Cursor और MCP सर्वरों के साथ, हमारे सपोर्ट इंजीनियर अपनी कोडबेस जांच में आवश्यक जानकारी को सीधे और तेज़ी से ला सकते हैं।

#यह पहचानना कि विफलता कहाँ हुई

जब कोई ग्राहक किसी त्रुटि की रिपोर्ट करता है, तो हमें यह समझना होता है: क्या उसे जो समस्या आ रही है वह दोहराई जा सकती है या अस्थायी है, और Cursor वास्तव में कहाँ विफल हुआ (क्लाइंट-साइड, API edge, downstream dependency, auth)। Datadog MCP हमें प्रासंगिक लॉग्स और ट्रेसेज़ को सीधे जांच थ्रेड में पुल करने देता है, जिससे हम संभावित कारणों को सीमित करना शुरू कर सकते हैं।

#समान मामलों का पता लगाना

जब कोई नया समर्थन टिकट आता है, तो अक्सर उस समस्या का सामना पहले किसी अन्य ग्राहक या हमारी टीम के किसी सदस्य ने किया होता है। आपके समर्थन प्लेटफ़ॉर्म और Slack, दोनों के साथ एकीकृत MCP हमें उस संदर्भ में सीधे खोज करने और जांच के लिए सबसे प्रासंगिक थ्रेड सामने लाने की सुविधा देता है। हम पहले पक्के पहचानकर्ताओं (एरर स्ट्रिंग, अनुरोध ID) से खोज शुरू करते हैं, ज़रूरत पड़ने पर दायरा बढ़ाते हैं, और सबसे नया ऐसा थ्रेड देखते हैं जिसमें मौजूदा स्थिति, कोई वैकल्पिक उपाय, और ज़िम्मेदार व्यक्ति का उल्लेख हो।

#यह तय करना कि क्या यह वाकई एक बग था

कई जांच आखिरकार इसी सवाल पर आकर टिकती हैं: "बग या अपेक्षित व्यवहार?" Notion MCP हमें प्रासंगिक रनबुक को थ्रेड में लाने, उसे हम जो देख रहे हैं उससे मिलान करने, और फिर या तो उस व्यवहार की पुष्टि करने या कहीं अधिक स्पष्ट बग रिपोर्ट के साथ उसे आगे बढ़ाने में मदद करता है।

#बग रिपोर्ट दर्ज करना

Cursor में जांच पूरी होने तक, अगर किसी चीज़ को ठीक करने की ज़रूरत हो, तो इंजीनियरिंग के लिए टिकट दर्ज करने हेतु हमारे पास ज़रूरी सारी सामग्री इकट्ठा हो चुकी होती है। Linear MCP हमें उस पूरे संदर्भ को लेकर उसी थ्रेड से सीधे एक सुव्यवस्थित एस्केलेशन में बदलने देता है।

#दस्तावेज़ीकरण अपडेट

जब कई ग्राहकों के एक जैसे प्रश्न होते हैं, तो यह अक्सर इस बात का संकेत होता है कि हमें अपने दस्तावेज़ीकरण को बेहतर बनाना चाहिए। तकनीकी समर्थन टीम इस तरह के सुधार सीधे लागू करने के लिए सबसे उपयुक्त स्थिति में होती है। हम बस Slack में @Cursor का उल्लेख करके बताते हैं कि क्या अपडेट करना है, और एक क्लाउड एजेंट हमारे दस्तावेज़ रेपो के लिए PR खोल देता है।

#प्रक्रिया का स्वचालन

#सामान्य चरणों के लिए कमांड

हम प्रक्रिया में बार-बार आने वाले चरणों के लिए स्लैश कमांड का उपयोग करते हैं:

# समर्थन टिकट बनाएँ
रिपोर्ट किए गए बग या उपयोगकर्ता की समस्या के लिए Linear में एक टिकट बनाएँ।

## प्रारूप
- **रिपोर्टर की जानकारी:** ईमेल, खाता ID, प्लेटफ़ॉर्म, ऐप संस्करण
- **सारांश:** 1-2 वाक्यों में संक्षिप्त विवरण
- **अपेक्षित बनाम वास्तविक:** क्या होना चाहिए बनाम वास्तव में क्या हो रहा है
- **पुनरुत्पादन के चरण:** क्रमांकित सूची

## नोट्स
- टिकट बनाने से पहले लॉग्स से उपयोगकर्ता की जानकारी जुटाएँ
- यदि उपलब्ध हों, तो अनुरोध IDs या trace IDs शामिल करें
- संबंधित लॉग क्वेरी या डैशबोर्ड के लिंक शामिल करें
- जब तक अलग से न बताया गया हो, डिफ़ॉल्ट रूप से Medium प्राथमिकता रखें

# ग्राहक उत्तर का मसौदा तैयार करें
ग्राहक को उसकी समस्या के बारे में भेजे जाने वाले उत्तर का मसौदा तैयार करें।

## दिशानिर्देश
- केवल सार्वजनिक उत्पाद नाम का उपयोग करें
- आंतरिक सेवा नाम, कोडनेम या इन्फ्रास्ट्रक्चर विवरण से बचें
- आंतरिक त्रुटि कोड, फ़ाइल पथ या एनवायरनमेंट वेरिएबल्स साझा न करें
- सार्वजनिक रूप से प्रलेखित सुविधाओं और मानक समस्या निवारण चरणों तक ही सीमित रहें

## संदेह होने पर
पूछें: "क्या कोई ग्राहक सामान्य उत्पाद उपयोग के दौरान इसे खोज सकता है?"
अगर नहीं, तो सामान्य डीबगिंग तरीकों का उपयोग करके इसे दोबारा लिखें।

# ज्ञात समस्याओं के लिए खोजें
यह पता लगाने के लिए Slack में खोजें कि क्या यह समस्या पहले से ज्ञात है।

## वर्कफ़्लो
1. पहचानकर्ताओं के साथ खोजें (टिकट ID, त्रुटि कोड, सटीक त्रुटि संदेश)
2. चैनल और समय सीमा के आधार on खोज को सीमित करें
3. ऐसे थ्रेड खोजें जिनमें स्थिति, workaround या owner की जानकारी हो

## आउटपुट
- **निष्कर्ष:** ज्ञात / संभवतः ज्ञात / नहीं मिला
- **सर्वश्रेष्ठ थ्रेड:** Permalink + सारांश
- **अगली खोज:** अगर नतीजे कमज़ोर हों, तो आज़माने के लिए क्वेरी

# लॉग्स खोजें
निर्दिष्ट अनुरोध, उपयोगकर्ता या त्रुटि के लिए Datadog लॉग्स में क्वेरी करें।

## सामान्य पैटर्न
- @requestId:{id} — किसी विशिष्ट अनुरोध को खोजें
- @userId:{id} or @email:{email} — उपयोगकर्ता गतिविधि खोजें
- status:error — केवल त्रुटियों तक फ़िल्टर करें
- service:{name} — सेवा के आधार पर फ़िल्टर करें

## नोट्स
- हमेशा एक समय सीमा निर्दिष्ट करें (डिफ़ॉल्ट: पिछले 7 दिन)
- फ़ील्ड नाम स्रोत के अनुसार बदल सकते हैं—कई पैटर्न आज़माएँ
- पहले व्यापक खोज से शुरू करें, फिर निष्कर्षों के आधार पर उसे सीमित करें

#दोहराए जाने वाले पैटर्न के लिए नियम और कौशल

हम समर्थन जांचों में सामान्य प्रक्रियाओं को स्वचालित करने के लिए नियमों और कौशलों का उपयोग करते हैं।

# Skill: ग्राहक को जवाब (सुरक्षित + कार्रवाई योग्य)

## आवश्यक इनपुट
- ग्राहक की समस्या के लक्षण (उन्हें क्या दिख रहा है)
- हमने क्या पाया (तथ्य-आधारित सारांश)
- अगला चरण/वैकल्पिक उपाय (यदि कोई हो)
- पूछने के लिए 0–2 अनुपलब्ध डेटा पॉइंट

## आउटपुट प्रारूप
- संक्षिप्त स्वीकारोक्ति
- हमने क्या पाया (कोई आंतरिक विवरण नहीं)
- आगे क्या आज़माना है (क्रमांकित चरण)
- यदि ज़रूरी हो: अधिकतम दो प्रश्न (जांच को आगे बढ़ाने के लिए)
- अंत में बताएँ कि हमारी ओर से अगला कदम क्या होगा

## दिशानिर्देश
- आंतरिक कार्यान्वयन विवरण और आंतरिक शब्दजाल से बचें
- अनुमान के बजाय ठोस चरणों को प्राथमिकता दें
- इसे संक्षिप्त रखें; "पहला उपयोगी जवाब" देने पर ध्यान दें

# Skill: उच्च-गुणवत्ता वाले बग टिकट का मसौदा तैयार करें

## आवश्यक इनपुट
- लक्षण (जो ग्राहक को दिखाई दे रहा हो)
- समयावधि
- कोई भी ID (`request id`, `user/team id`)
- साक्ष्य के अंश (संवेदनशील जानकारी हटाकर)

## आउटपुट प्रारूप
## सारांश
## अपेक्षित बनाम वास्तविक
## पुनरुत्पन्न करने के चरण
## साक्ष्य
## दायरा/गंभीरता
## डीबगिंग का अगला सुझाया गया चरण

## गुणवत्ता मानक
- बिना किसी ठोस स्थिति के अस्पष्ट भाषा ("कभी-कभी", "काम नहीं करता") का उपयोग न करें
- शीर्षक में केवल आंतरिक शब्दजाल न हो
- जब तक स्पष्ट स्वीकृति न हो, ग्राहक-विशिष्ट जानकारी हटा दें

# Skill: ज्ञात समस्याओं का शोधकर्ता (Slack + Notion)

## आवश्यक इनपुट
- त्रुटि का सटीक पाठ (या उसका सबसे अच्छा अनुमान)
- फ़ीचर क्षेत्र से जुड़े कीवर्ड
- समयावधि (डिफ़ॉल्ट: पिछले 30 दिन)

## वर्कफ़्लो
- पहले Slack में सटीक वाक्यांशों और पहचानकर्ताओं को खोजें।
- अगर परिणाम कमज़ोर हों, तो फ़ीचर कीवर्ड और समय फ़िल्टर के साथ खोज का दायरा बढ़ाएँ।
- उसी फ़ीचर क्षेत्र के लिए runbooks/FAQs को Notion में खोजें।

## आउटपुट प्रारूप
- निष्कर्ष: ज्ञात / संभवतः ज्ञात / नहीं मिला
- सबसे अच्छे थ्रेड: 1–3 लिंक, साथ में एक-पंक्ति "क्यों प्रासंगिक"
- वैकल्पिक उपाय / असर कम करने का तरीका (यदि मौजूद हो)
- अगला खोज परिष्करण: आगे चलाने के लिए सटीक क्वेरी

#चरणों को समानांतर में चलाने के लिए उप-एजेंट

उप-एजेंट हमें समर्थन प्रक्रिया के सामान्य चरणों को क्रमवार चलाने के बजाय समानांतर में चलाने देते हैं।

• LogInvestigator Datadog में विफलता के बिंदु और उससे जुड़े सहायक साक्ष्य खोजता है।
• KnownIssueMiner पुराने थ्रेड और वैकल्पिक उपाय खोजने के लिए Slack और Notion को स्कैन करता है।
• TicketWriter साक्ष्य को एक पूर्ण एस्केलेशन के रूप में प्रारूपित करता है।
• CustomerReplyDrafter आंतरिक विवरण हटाकर ग्राहक के लिए जवाब तैयार करता है।

परिणाम एक ही आउटपुट में मर्ज हो जाते हैं, जिसकी हम समीक्षा करके भेजते हैं।

supportInvestigationPack:
  goal: >
    Produce a grounded investigation summary, a draft bug ticket,
    and a customer reply by running specialized agents in parallel.
  inputs:
    - customer_symptom
    - time_window
    - identifiers:
        request_id: ""
        user_or_team_id: ""
        error_text: ""
    - investigation_notes
  agents:
    - name: LogInvestigator
      focus: "Datadog: identify the most likely failure point and supporting evidence."
      output:
        - suspected_root_cause
        - strongest_evidence
        - disconfirming_checks
        - open_questions
    - name: KnownIssueMiner
      focus: "Slack/Notion: find prior art, current status, and workaround."
      output:
        - verdict
        - best_links
        - workaround
        - next_search_query
    - name: TicketWriter
      focus: "Write an engineering-facing bug ticket from evidence + notes."
      output:
        - title
        - summary
        - expected_vs_actual
        - steps_to_repro
        - evidence
        - suggested_next_debug_step
    - name: CustomerReplyDrafter
      focus: "Draft a customer reply: clear, safe, and actionable."
      constraints:
        - "Do not include internal implementation details."
        - "Ask for at most two missing data points."
      output:
        - reply_text
        - questions_for_customer
  final_assembler:
    merges:
      - LogInvestigator
      - KnownIssueMiner
      - TicketWriter
      - CustomerReplyDrafter
    produces:
      - investigation_summary
      - ticket_draft
      - customer_reply

#AI-नेटिव तकनीकी समर्थन

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

अगर आप यह जानना चाहते हैं कि Cursor को अपने CX वर्कफ़्लो में कैसे शामिल किया जाए, तो संपर्क करें।