يطلب المسافر تأجيل الذهاب يومين مع إبقاء العودة. يظهر زر «تعديل»، لكن ما خلفه قد يكون طلب عرض جديد أو انتظار موافقة أو إجراءً يدويًا لدى المزود. هذه الفروق تغيّر نطاق تطوير منصة السفر، ولا تختصر في إضافة شاشة بتاريخ جديد.
قبل التسعير، حدد أنواع الحجوزات والتغييرات التي ستدعمها، وما يمكن تنفيذه آليًا وما يحتاج متابعة موظف. واطلب من المنفذ إثبات حدود مزود الربط الذي سيستخدمه، بدل تعميم إمكان تغيير كل تذكرة بالشكل نفسه.
ابدأ بالحجز الذي سيبقى جزء منه كما هو
في مثال افتراضي لمنصة سفر للشركات، يريد موظف تأجيل الذهاب مع الاحتفاظ بالعودة. قد يصل عرض تغيير ثم تنتهي صلاحيته قبل موافقة المسؤول. المثال لا يتضمن حجزًا أو راكبًا أو سعرًا فعليًا، بل يكشف أسئلة النطاق قبل بناء المسار.
اكتب مرجع الحجز والمسافرين والأجزاء المطلوب تغييرها وما ينبغي بقاؤه، والجهة المخولة بطلب التغيير واعتماد أثره. لا تجعل تحديث تاريخ ظاهر في حساب الموظف دليلًا على تعديل حجز الناقل، ولا تفترض أن موافقة المدير الداخلي تساوي موافقة المزود.
مصفوفة تفصل الطلب عن التأكيد
استخدم الحالات التالية لتحديد المعنى أمام العميل وفريق المتابعة. تسمياتها مقترحة؛ على المنفذ ربطها بالحالات والأدلة التي يوفرها المزود الفعلي، وتوضيح أي حالة لا يستطيع إثباتها.
| الحالة | ما تعنيه في المسار المقترح | ما لا تستنتجه منها |
|---|---|---|
| طلب تعديل | سجلنا المطلوب ومن يملكه | توفر رحلة بديلة أو سعر نهائي |
| عرض تغيير | بديل بشروط ومبلغ وعملة ومدة صلاحية | أن الحجز تغير أو أن العرض سيبقى متاحًا |
| تغيير معلق | اختيار ينتظر خطوة التأكيد بحسب المزود | صدور التأكيد أو اكتمال كل تسوية |
| تأكيد مثبت | مرجع ودليل يبينان ما تغير بالفعل | أن كل خدمة إضافية أو رد مبلغ أُغلق تلقائيًا |
| متابعة يدوية | مالك وخطوة تالية لعمل غير متاح آليًا | رفض التغيير بالضرورة أو إنجازه من مجرد إحالة |
تفرق وثائق Duffel بين عرض التغيير وإنشاء تغيير معلق وتأكيده. كما تعرض شروط الحجز والأفعال المتاحة عبر API، وتوضح أن السماح بالتعديل لا يثبت دائمًا إمكان تنفيذه آليًا. هذه أمثلة مزود محدد، لا ضمان تغطية لكل ناقل أو اتفاق.
ما الذي يحدث عندما ينتهي العرض؟
اطلب حالة اختبار يتأخر فيها الاعتماد حتى تنتهي صلاحية العرض. ماذا يراه الموظف، ومن يطلب بديلًا، وهل يحتاج المبلغ أو الشروط الجديدة موافقة أخرى؟ لا تسمح باستعمال موافقة قديمة على نتيجة تغيرت دون قرار واضح من صاحب الصلاحية.
راجع أيضًا ترتيب الخطوات إذا وصل الطلب من مستخدمين، أو تغير الحجز من قناة أخرى أثناء الانتظار. المطلوب في هذه المقالة حفظ سياق التعديل ودليل حالته، لا فرض آلية تقنية واحدة للتزامن أو إعادة المحاولة. يشرح المزود والمنفذ ما يمكن التحقق منه وما يبقى معلقًا.
اعرض الأثر المالي دون خلطه بالرحلة
حدد المبلغ والعملة ومكوناتهما كما يقدمهما المزود، ومن يراجعها ويوافق عليها، وما الذي تتولاه المنصة من تحصيل أو متابعة. لا تستنتج من عبارة «تغيير مسموح» أنه مجاني، أو أن قيمة موجبة أو سالبة تصلح سياسة موحدة لكل حجز.
توضح وثائق التأكيد أن معالجة مبلغ راجع قد تتطلب خطوة تجاه العميل بعد إرجاعه إلى وسيلة لدى المزود. لذلك افصل حالة الرحلة عن حالة التحصيل والاسترداد، وحدد مسؤول كل متابعة. لا يقدم هذا المثال حقوق استرداد قانونية أو رسومًا أو آجالًا مضمونة.
جهز مسارًا للعمل الذي يبقى يدويًا
إذا لم يدعم الربط تغييرًا معينًا، فحدد فريق المتابعة والمرجع والمعلومات اللازمة والخطوة التالية وما يظهر للمستخدم أثناء الانتظار. لا تترك الطلب في حالة عامة لأن الواجهة لا تملك زر تنفيذ مناسبًا، ولا تعد بأن إحالة البلاغ تعني موافقة الناقل.
وافصل تعديلًا طلبه المسافر عن تغيير بدأه الناقل؛ قد تختلف الخيارات والموافقات والإشعارات. قبل قبول التكلفة، اطلب قائمة بالحالات المشمولة والمستثناة ومصدر إثباتها، وتجربة آمنة لعرض منتهٍ وتأكيد ناجح وحالة تحتاج متابعة، ببيانات اختبار مصرح بها.
راجع اعتماديات الطرف الثالث وموجز تسعير الربط، وأرفق مصفوفة التغيير عند طلب منصة ويب من نكست ويف ليظهر العمل خارج الشاشة ضمن العرض.
المراجع وحدود التغطية
فُتحت أقسام محددة من وثائق Duffel عن عروض التغيير والتغييرات وتأكيدها وشروط الحجز وأفعاله في 4 نوفمبر 2026. المصفوفة والمثال مقترحان دون حجز أو API أو تحصيل أو مراسلات فعلية. الإعداد بمساعدة الذكاء الاصطناعي مع مراجعة المعلومات والترجمة.
