Travel Agency में Claude Code से सुरक्षित Itinerary और Quote कैसे बनाएँ

कल्पना कीजिए कि शुक्रवार की शाम कई inquiries एक साथ आ जाती हैं। एक काल्पनिक request है: अगले weekend पति-पत्नी के लिए Jaipur में 2 रात, लगभग 40,000 रुपये का budget, heritage palaces और rooftop dinner। Planner को availability, travel time, rates, terms और typo सभी जाँचकर proposal तैयार करना है।

यह ClaudeCodeLab का बनाया हुआ पूरी तरह काल्पनिक test scenario है। इसमें किसी असली customer, booking, supplier quote या travel agency के operational data का उपयोग नहीं किया गया। उद्देश्य यह दिखाना है कि Claude Code को itinerary का draft और quote calculation कैसे सौंपें, और किन फैसलों पर इंसान का control बना रहे।

यह workflow समय बचाने का दावा नहीं करता। पहले baseline मापें, फिर उसी तरह के sample पर pilot चलाएँ। AI को क्या सौंपें और इंसान कहाँ ज़रूर फैसला करे, इस line को साफ़ खींचना ही safe उपयोग की शर्त है।

मुख्य बातें

Itinerary, quote और proposal का “जोड़ना और साफ़ लिखना” AI अच्छा करता है। Planner destination चुनने और customer से बात करने पर ध्यान दे सकता है।
सीधे इस्तेमाल होने वाला prompt template, और rate की calculation की गलती machine से पकड़ने वाला verification script नीचे दिया है।
Rate, availability, cancellation policy जैसे “गलत हो तो हादसा बन जाए” वाले numbers इंसान ज़रूर check करे। यही line safe उपयोग की शर्त है।
Personal information — नाम, booking number — masking करके ही AI को दें। Raw data कभी paste न करें, यह नियम पहले तय कर लें।
समय की बचत को अनुमान मानने के बजाय baseline और pilot timestamps से मापें; नीचे calculation formula दिया है।

Travel agency का काम भारी कहाँ पड़ता है

पढ़ने वाले आप शायद store या corporate sales में custom-made trips बनाने वाले planner हैं। Ready package बेचने के बजाय जिनका काम requirement सुनकर शुरू से plan बनाने का है, उन्हें यह article ज़्यादा काम का लगेगा।

Custom proposal आमतौर पर ऐसे आगे बढ़ता है।

Hearing: destination, लोगों की संख्या, बजट, पसंद, must-have conditions पूछना
Material gathering: होटल, travel, local experiences के candidates और rates ढूँढना
Assembly: travel time और availability देखते हुए schedule में डालना
Quote: accommodation, travel, handling fee, tax जोड़कर grand total निकालना
Clean-up: itinerary और proposal में साफ़ करना, notes जोड़ना
Present और revise: customer को देना, “दूसरे दिन में sightseeing ज़्यादा” जैसे बदलाव लाना

इनमें 1 और 6 इंसान के judgment पर रहने चाहिए। Customer की priorities और budget की असली सीमा समझना बातचीत का काम है। दूसरी तरफ़ 3 से 5 तक तय material को तय खाँचे में डालने का काम है। Inquiry की complexity के अनुसार इसमें लगने वाला समय बदलता है, इसलिए अंदाज़े के बजाय हर चरण का start और end time दर्ज करना चाहिए।

“दूसरे दिन को थोड़ा आराम वाला कर दो” सुनते ही travel time और rate सब फिर से जोड़ने पड़ते हैं। Excel की एक row खिसकाते ही total बिगड़ जाता है, और बिना ध्यान दिए भेज देने पर शर्मिंदगी होती है। ऐसे छोटे हादसे field में दबे-दबे काफ़ी होते हैं।

AI को क्या सौंपें, और इंसान कहाँ ज़रूर फ़ैसला करे

इसे धुंधला रखा तो हादसा होगा। पहले line खींच लेते हैं।

चरण	AI को सौंपें	इंसान ज़रूर तय करे
Hearing	सवालों में छूटी बातें check करना	बजट की असली बात, तालमेल, माहौल पढ़ना
Material gathering	candidates की शुरुआती जाँच, comparison table	availability की आखिरी पुष्टि, सुझाव का चयन
Assembly	travel time देखते हुए schedule का draft	route थका देने वाला तो नहीं, fitness के मुताबिक है या नहीं
Quote	formula बनाना, total का draft	purchase rate, exchange rate, cancellation policy के numbers
Clean-up	itinerary व proposal में formatting, typo check	final approval, customer के नाम की पुष्टि

याद रखने लायक line एक ही है: “गलत हो तो refund या complaint बन जाए” वाले numbers इंसान ज़रूर check करे। Rate, availability, cancellation fee, age-wise rate, exchange rate। यहाँ AI के draft पर भरोसा न करें — supplier के official rate से मिलान करें। AI तेज़ clean-up clerk है, rate की guarantee नहीं देता।

Use case 1: Requirement note से itinerary का draft बनाना

Hearing के notes आमतौर पर बिखरे bullet points होते हैं। इन्हें schedule की shape में लाने वाला repetitive हिस्सा AI को दिया जा सकता है, जबकि route की suitability planner जाँचता है।

सीधे इस्तेमाल होने वाला prompt template यह रहा।

आप एक experienced travel agency planner हैं।
नीचे दिए requirement note से, ऐसा itinerary draft बनाइए जिसमें travel time
पर ज़्यादा बोझ न पड़े।

# Requirement note
- Destination: Jaipur
- अवधि: 2 रात 3 दिन
- लोग: पति-पत्नी 2 लोग
- बजट: कुल लगभग 40,000 रुपये
- इच्छा: heritage palaces, रात में rooftop dinner, travel ठूँस-ठूँसकर न हो

# Output rules
- हर दिन को "सुबह / दोपहर / रात" में बाँटें
- हर item में अनुमानित समय और travel का साधन लिखें
- जहाँ travel 1 घंटे से ज़्यादा हो, वहाँ "★travel लंबा" note करें
- जहाँ rate चाहिए, वहाँ [confirm:rate] लिखें, खुद से numbers न भरें
- आखिर में "confirm करने वाले items" की list bullet points में दें

आखिरी दो lines ही असली बात हैं। Rate खुद से न भरवाएँ — [confirm:rate] placeholder रखें। इससे AI के झूठे-से दिखने वाले rate लिख देने वाला हादसा रुक जाता है। आए हुए draft में आप supplier से लिया official rate भरें। यह role-division हो तो बेफ़िक्र होकर इस्तेमाल कर सकते हैं।

Claude Code की basic operations से अभी सहज नहीं हैं, तो पहले Claude Code शुरू करने की गाइड पढ़ लें, फिर यह template तुरंत आज़मा पाएँगे।

Use case 2: Quote के total की गलती machine से पकड़ना

Proposal में सबसे डरावना है rate का जोड़ गलत होना। एक रात दो meal प्रति व्यक्ति, tax और service charge, handling fee। Excel में बनाते वक्त एक row जोड़ते ही sum-range खिसक जाता है, और बिना ध्यान दिए कम amount पर भेज देते हैं। यह माफ़ी और अंतर की रकम अपनी जेब से भरने वाला रास्ता है।

इसलिए नीचे quote का breakdown machine से check करने वाला script दिया है। Node.js हो तो चल जाता है। यह breakdown के subtotals को फिर से जोड़कर, present किए grand total से मिलान करता है।

// verify-quote.mjs  breakdown और grand total मिलते हैं या नहीं, जाँचता है
// चलाएँ: node verify-quote.mjs

const quote = {
  customer: "(masked) जी",
  items: [
    { label: "रात 1 - Hotel A - 2 लोग", amount: 9600 },
    { label: "रात 2 - Hotel B - 2 लोग", amount: 10400 },
    { label: "Train आना-जाना - 2 लोग", amount: 11200 },
    { label: "Local guide - आधा दिन", amount: 3600 },
    { label: "Handling fee", amount: 1600 },
  ],
  tax: 2880, // GST वगैरह
  presentedTotal: 39280, // proposal में लिखा grand total
};

const subtotal = quote.items.reduce((sum, item) => sum + item.amount, 0);
const calcTotal = subtotal + quote.tax;

console.log(`Subtotal: ${subtotal.toLocaleString()} रुपये`);
console.log(`Tax:      ${quote.tax.toLocaleString()} रुपये`);
console.log(`Calculated total: ${calcTotal.toLocaleString()} रुपये`);
console.log(`Proposal total:   ${quote.presentedTotal.toLocaleString()} रुपये`);

if (calcTotal === quote.presentedTotal) {
  console.log("OK: breakdown और grand total मिलते हैं");
} else {
  const diff = quote.presentedTotal - calcTotal;
  console.log(`NG: ${Math.abs(diff).toLocaleString()} रुपये का फ़र्क है। proposal भेजने से पहले ठीक करें`);
  process.exit(1);
}

इस script में presentedTotal को proposal के number से मिलाकर रखें, तो फ़र्क आते ही NG पर रुक जाता है। Customer को देने से पहले का आख़िरी द्वारपाल। items के unit rate तो इंसान supplier से confirm किया हुआ ही भरे, यह मान लिया गया है — यहाँ सिर्फ़ verification होती है। Verification और rate-confirm अलग हैं, यह समझकर चलना ज़रूरी है।

Prompt की accuracy और बढ़ानी हो, तो Prompt की accuracy बढ़ाने के tips भी साथ देखें।

Use case 3: “दूसरा दिन आराम वाला” revision एक बार में लागू करना

Present के बाद का revision AI के लिए उपयोगी काम है। हर requirement पर पूरा itinerary दोबारा लिखने के बजाय, बदलाव को सीमित करके यह prompt दें।

पिछले itinerary में नीचे दिए बदलाव लागू करें।
- दूसरा दिन: सुबह का एक plan कम करें, दोपहर में hotel पर 1 घंटे का आराम जोड़ें
- इससे travel जहाँ बदले, वहाँ अनुमानित समय फिर से लिखें
- जिन items का rate बदले, उन्हें [confirm:rate] पर लौटा दें
- बदले हुए हिस्से के आगे "▼बदला" लगाएँ और एक line में बताएँ क्या बदला

“बदले हिस्से पर निशान लगाओ” कहना उपयोगी है। क्या बदला, एक नज़र में दिखता है, इसलिए reviewer सिर्फ़ बदली हुई जगहों और उनसे प्रभावित totals पर ध्यान दे सकता है। जिन items का rate हिलता है, उन्हें [confirm:rate] पर लौटवाएँ और recalculation इंसान के control में रखें।

Itinerary और proposal के template project को याद करा रखें, तो हर बार शून्य से निर्देश नहीं देना पड़ता। तरीका CLAUDE.md लिखने का तरीका में मिल जाएगा।

Copy-paste वाली confirmation checklist

Proposal भेजने से पहले की आख़िरी जाँच कागज़ पर हो या note में, हर बार इसी से गुज़ारें।

Rate supplier के official quote से मिलाया?
Availability की आख़िरी पुष्टि की? (AI के draft पर भरोसा तो नहीं किया?)
Cancellation policy और age-wise rate body में डाला?
Verification script चलाकर total मिलाया?
Customer का नाम और booking number सही form में लौटाया?
Travel time पर बोझ तो नहीं (बुज़ुर्ग या छोटे बच्चों के साथ ख़ास तौर पर)?

Personal information और security की सावधानी

Trip arrangement नाम, जन्मतिथि, passport number, booking number — sensitive जानकारी का गुच्छा है। इसे जस का तस AI में paste करने से बचें।

नियम सीधे दो हैं। एक, personal information masking करके ही दें। नाम को “A जी”, booking number को “(masked)” से बदलें। Assembly और clean-up के लिए असली नाम की ज़रूरत नहीं। दो, raw data local पर रखें, सिर्फ़ आख़िरी नाम डालना इंसान हाथ से करे। AI से template बनवाएँ, व्यक्ति पहचानने वाली जानकारी हाथ से भरें। यह क्रम निभाएँ तो बाहर जाकर परेशानी देने वाली जानकारी नहीं बहती।

कंपनी के तौर पर अपनाना हो, तो क्या देना ठीक और क्या नहीं — यह लिखित रूप में तय कर लें तो safe रहता है। Team में line खींचने का काम Training और consultation में साथ मिलकर organize कर सकते हैं। मापदंड धुंधला रखकर सबको दे दिया, तो कोई न कोई raw data ज़रूर paste कर देगा।

समय और ROI मापने का plan

नीचे की table कोई achieved result नहीं है। यह pilot चलाते समय भरने वाला measurement plan है। एक ही तरह की inquiry को manual baseline और Claude Code-assisted pilot में चलाकर timestamps दर्ज करें।

मापने वाला चरण	Baseline में दर्ज करें	Pilot में दर्ज करें
Requirement note से पहला draft	शुरू और पूरा होने का समय	वही timestamps और इस्तेमाल किया prompt
Rate confirmation व total check	manual checking का समय और errors	human confirmation का समय और script result
Revision	request मिलने से approval तक	बदली lines, review time और दोबारा calculation
Final approval	reviewer और correction count	reviewer, placeholders और PII check

काल्पनिक ROI example: अगर measured baseline 90 मिनट और pilot 70 मिनट निकले, और महीने में 60 समान proposals हों, तो अनुमानित बचत 60 × (90 - 70) ÷ 60 = 20 घंटे/माह होगी। यह guarantee नहीं है; अपने actual timestamps, review cost और tool cost डालकर ही adoption का फैसला करें।

Non-engineer भी इस्तेमाल कर पाएँगे या नहीं, इसकी फ़िक्र हो, तो Engineer न होने पर भी Claude Code पढ़ने से पहले कदम की झिझक कम होगी। रोज़मर्रा की गति बढ़ाने के लिए Claude Code productivity tips भी काम के हैं।

अक्सर पूछे जाने वाले सवाल

Q. डर है कि AI rate खुद से तय कर देगा। A. Prompt में [confirm:rate] इस्तेमाल करें और numbers न भरवाएँ। Rate में सिर्फ़ इंसान का supplier से confirm किया value डलें। AI को formula और clean-up का clerk मानकर role fix कर दें, तो वह बेलगाम नहीं होगा।

Q. Customer का असली नाम और booking number डालना ठीक है? A. मत डालिए। Masking करके दें, और सिर्फ़ आख़िरी नाम डालना हाथ से करें। Assembly और clean-up में personal name की ज़रूरत नहीं।

Q. हमारे पास अपना itinerary template है। क्या वह reproduce होगा? A. हाँ। अपना format और writing rules project को याद करा दें, तो हर बार उसी के मुताबिक output मिलेगा। विस्तार के लिए official documentation में setup का तरीका देखें।

Q. पूरी तरह automate करके इंसान का check हटा सकते हैं? A. सुझाव नहीं देता। Rate, availability, cancellation policy की पुष्टि इंसान के हाथ रहे, यह शर्त है। इसे हटाया तो गलती सीधे customer तक पहुँचती है। समय की बचत सिर्फ़ “assembly और clean-up” तक रखना safe है।

काल्पनिक data पर वास्तव में किए गए test का परिणाम

ClaudeCodeLab ने ऊपर के verify-quote.mjs को केवल article में दिए काल्पनिक values के साथ चलाया। सही presentedTotal पर script ने OK दिखाया। फिर displayed total में जानबूझकर 100 रुपये का छोटा फर्क डाला; script ने NG दिखाकर process status 1 के साथ exit किया। किसी supplier से लिया rate या असली booking इसमें शामिल नहीं थी।

Itinerary prompt को भी उसी fictional Jaipur request पर चलाकर output को manually review किया गया। Review में यह देखा गया कि rate की जगह [confirm:rate] placeholders बने रहे और output में नाम, booking number, passport number या दूसरी personally identifiable information (PII) नहीं थी। इस test से production accuracy या समय की बचत सिद्ध नहीं होती।

सिद्ध हुआ केवल यह कि sample calculation में सही total pass होता है, बदला total fail होता है, और prompt placeholder/PII rules को review किया जा सकता है। Production में जाने से पहले masked historical cases पर अपना pilot चलाएँ। पहली बार Claude Code चलाना हो तो Claude Code शुरू करने की गाइड देखें। Team के लिए data और approval rules तय करने हों, तो मुख्य अगला कदम Training और consultation है।