نماذج التسعير لحل متعدد المستأجرين

يضمن نموذج التسعير الجيد أن تظل مربحا مع زيادة عدد المستأجرين وأثناء إضافة ميزات جديدة. تعد كيفية تصميم نماذج تسعير لمنتجك أحد الاعتبارات المهمة عند تطوير حل تجاري متعدد المستأجرين. نقدم في هذه الصفحة إرشادات لصانعي القرار التقنيين حول نماذج التسعير التي يمكنك مراعاتها والمفاضلات المضمنة.

ينبغي، عند تحديد نموذج التسعير لمنتجك، موازنة العائد على القيمة (ROV) للعملاء مع تكلفة البضائع المبيعة (COGS) لتقديم الخدمة. قد يؤدي تقديم نماذج تجارية أكثر مرونة (لحل) إلى زيادة ROV للعملاء، لكنه قد يؤدي أيضا إلى زيادة التعقيد الهيكلي والتجاري للحل (وبالتالي يزيد أيضا من COGS لديك).

بعض الاعتبارات الهامة التي يجب مراعاتها عند تطوير نماذج التسعير لحل، هي كما يلي:

• هل ستكون تكلفة البضائع المبيعة (COGS) أعلى من الربح الذي تحققه من الحل؟
• هل يمكن أن تتغير COGS بمرور الوقت، بناء على نمو المستخدمين أو التغييرات في أنماط الاستخدام؟
• ما مدى صعوبة قياس وتسجيل المعلومات اللازمة لتشغيل نموذج التسعير؟ على سبيل المثال، إذا كنت تخطط لفوترة عملائك استنادا إلى عدد استدعاءات واجهة برمجة التطبيقات التي يقومون بها، هل حددت كيفية قياس استدعاءات واجهة برمجة التطبيقات التي أجراها كل عميل؟
• هل تعتمد الربحية لديك على ضمان استخدام العملاء للحل بطريقة محدودة؟
• إذا أفرط العميل في استخدام الحل، فهل يعني ذلك أنك لم تعد مربحا؟

هناك بعض العوامل الرئيسية التي تؤثر على الربحية:

• نماذج تسعير خدمة Azure. قد تؤثر نماذج التسعير لخدمات Azure أو الجهات الخارجية التي تشكل الحل الخاص بك على النماذج المربحة.
• أنماط استخدام الخدمة. قد يحتاج المستخدمون فقط إلى الوصول إلى الحل أثناء ساعات العمل أو قد يكون لديهم نسبة صغيرة فقط من المستخدمين ذوي الحجم الكبير. هل يمكنك تقليل COGS بتقليل السعة غير المستخدمة عندما يكون استخدامك منخفضا؟
• نمو التخزين. تجمع معظم الحلول البيانات بمرور الوقت. يعني المزيد من البيانات تكلفة أكبر لتخزينها وحمايتها، ما يقلل من ربحية كل مستأجر. هل يمكنك تعيين حصص التخزين النسبية أو فرض فترة استبقاء البيانات؟
• عزل المستأجر. يؤثر نموذج الإيجار الذي تستخدمه على مستوى العزل بين المستأجرين لديك. في حالة مشاركة مواردك، هل ينبغي لك مراعاة كيفية استخدام المستأجرين للخدمة بشكل مفرط أو إساءة استخدامها؟ كيف سيؤثر مستوى عزل المستأجر على COGS وأدائك للجميع؟ بعض نماذج التسعير ليست مربحة دون ضوابط إضافية حول تخصيص الموارد. قد تحتاج، على سبيل المثال، إلى إتمام تقييد الخدمة لجعل نموذج التسعير بالمعدل الثابت مستداما.
• دورة حياة المستأجر. على سبيل المثال، قد تعاني الحلول ذات معدلات خسارة العملاء المرتفعة، أو الخدمات التي تتطلب جهدا أكبر على متن الطائرة، من انخفاض الربحية - خاصة إذا تم تسعيرها باستخدام نموذج قائم على الاستهلاك.
• متطلبات مستوى الخدمة. قد تعني مطالبة المستأجرين بمستويات أعلى من الخدمة أن الحل لديك لم يعد مربحا. من المهم أن تكون واضحا بشأن توقعات مستوى الخدمة للعملاء وأي التزامات لديك، حتى تتمكن من تخطيط نماذج التسعير وفقا لذلك.

نماذج التسعير الشائعة

هناك العديد من نماذج التسعير الشائعة التي غالبا ما تستخدم مع حلول متعددة المستأجرين. يرتبط كل نموذج من نماذج التسعير هذه بالمزايا والمخاطر التجارية، ويتطلب اعتبارات هيكلية إضافية. من المهم فهم الاختلافات بين نماذج التسعير هذه حيث يمكنك ضمان بقاء الحل لديك مربحا أثناء تطوره.

إشعار

يمكنك تقديم نماذج متعددة لحل أو دمج النماذج معا. يمكنك، على سبيل المثال، توفير نموذج لكل مستخدم للعملاء الذين لديهم أعداد مستخدمين مستقرة إلى حد ما، ويمكنك أيضا تقديم نموذج استهلاك للعملاء الذين لديهم أنماط استخدام متقلبة.

نموذج تسعير مستند إلى الاستهلاك

يشار إلى نموذج الاستهلاك أحيانا باسم ادفع وتحدث، أو PAYG. تزداد الإيرادات مع زيادة استخدام الخدمة لديك:

يمكنك، عند قياس الاستهلاك، مراعاة عوامل بسيطة مثل كمية البيانات التي تتم إضافتها إلى الحل. يمكنك، بدلا من ذلك، مراعاة مجموعة من سمات الاستخدام معا. توفر نماذج الاستهلاك العديد من الفوائد، ولكن قد يكون من الصعب تنفيذها في حل متعدد المستأجرين.

الفوائد: من منظور عملائك، هناك الحد الأدنى من الاستثمار المسبق المطلوب لاستخدام الحل الخاص بك، بحيث يكون لهذا النموذج حاجز منخفض أمام الدخول. من وجهة نظرك كمشغل الخدمة، تزداد تكاليف الاستضافة والإدارة مع زيادة استخدام العملاء والإيرادات لديك. يمكن أن تتسبب هذه الزيادة في جعله نموذج تسعير قابل للتوسع بدرجة كبيرة. تعمل نماذج تسعير الاستهلاك جيدا وبشكل خاص عندما تكون خدمات Azure المستخدمة في الحل مستندة إلى الاستهلاك أيضا.

التعقيد والتكلفة التشغيلية: تعتمد نماذج الاستهلاك على قياسات دقيقة للاستخدام وعلى تقسيم هذا الاستخدام حسب المستأجر. يمكن أن يكون هذا صعبا خاصة مع حل يحتوي على عدة مكونات موزعة. تحتاج إلى الاحتفاظ بسجلات استهلاك مفصلة للفوترة والتدقيق بالإضافة إلى توفير طرق للعملاء للوصول إلى بيانات الاستهلاك الخاصة بهم.

المخاطر: يمكن أن يحفز تسعير الاستهلاك العملاء على تقليل استخدام النظام لديك لتقليل التكاليف. بالإضافة إلى ذلك، تؤدي نماذج الاستهلاك إلى عمليات تدفق إيرادات غير متوقعة. يمكنك التخفيف من هذا بتقديم حجوزات السعة حيث يدفع العملاء مقابل مستوى معين من الاستهلاك مقدما. يمكنك، بصفتك موفر الخدمة، استخدام هذه الإيرادات للاستثمار في تحسينات الحل، أو تقليل التكلفة التشغيلية أو زيادة العائد على القيمة بإضافة الميزات.

إشعار

قد يؤدي تنفيذ عمليات حجز القدرة الإنتاجية ودعمها إلى زيادة تعقيد عمليات الفوترة داخل التطبيق الخاص بك. قد ينبغي أيضا مراعاة كيفية حصول العملاء على المبالغ المستردة أو استبدال حجوزات القدرة الإنتاجية، ويمكن لهذه العمليات أيضا إضافة تحديات تجارية وتشغيلية.

تسعير لكل مستخدم

يتضمن نموذج التسعير لكل مستخدم فرض رسوم على العملاء لديك استنادا إلى عدد الأشخاص الذين يستخدمون الخدمة، كما هو موضح في الرسم التخطيطي التالي.

نماذج التسعير لكل مستخدم شائعة جدا، نظرا لبساطة التنفيذ في حل متعدد المستأجرين. ومع ذلك، فهي مرتبطة بالعديد من المخاطر التجارية.

مزايا: عندما تحرر فاتورة للعملاء عن كل مستخدم، من السهل حساب عملية تدفق الإيرادات والتنبؤ بها. بالإضافة إلى ذلك وبافتراض أن لديك أنماط استخدام متسقة إلى حد ما لكل مستخدم، فتزيد الإيرادات بنفس معدل استخدام الخدمة ما يجعل هذا نموذجا قابلا للتوسع.

التعقيد والتكلفة التشغيلية: تميل النماذج لكل مستخدم إلى أن تكون سهلة التنفيذ. إلا أنه، ينبغي في بعض الحالات قياس الاستهلاك لكل مستخدم والذي يمكن أن يساعدك على ضمان بقاء COGS لمستخدم واحد مربحا. يمكنك، من خلال قياس الاستهلاك وربطه بمستخدم محدد، زيادة التعقيد التشغيلي للحل.

المخاطر: قد تؤدي أنماط استهلاك المستخدم المختلفة إلى انخفاض الربحية. قد يتسبب، على سبيل المثال، المستخدمون الثقيلون للحل في تكلفة أكثر من المستخدمين الخفيفين. بالإضافة إلى ذلك، لا ينعكس العائد الفعلي على القيمة (ROV) للحل من خلال العدد الفعلي لتراخيص المستخدمين التي تم شراؤها.

تسعير لكل مستخدم نشط

يشبه هذا النموذج التسعير لكل مستخدم لكن بدلا من طلب التزام مسبق من العميل بشأن عدد المستخدمين المتوقعين، يتم فرض رسوم على العميل فقط للمستخدمين الذين يسجلون الدخول بالفعل إلى الحل ويستخدمونه خلال فترة (كما هو موضح في الرسم التخطيطي التالي).

يمكنك قياس هذا في أي فترة استخدام. الفترات الشهرية شائعة، ويتم غالبا تسجيل هذا المقياس كمستخدمين نشطين شهريا أو MAU.

الفوائد: من منظور عملائك، يتطلب هذا النموذج استثمارا منخفضا ومخاطرا، لأن هناك القليل من الهدر؛ والتراخيص غير المستخدمة غير قابلة للفوترة. وهذا يجعلها جذابة بشكل خاص عند تسويق الحل أو تطوير الحل لعملاء المؤسسات الأكبر حجما. من وجهة نظرك كمالك الخدمة، ينعكس ROV بشكل أكثر دقة على العميل من خلال عدد المستخدمين النشطين شهريا.

التعقيد والتكلفة التشغيلية: تتطلب منك نماذج المستخدم النشط تسجيل الاستخدام الفعلي وإتاحته للعميل كجزء من الفاتورة. يساعد قياس استهلاك كل مستخدم على ضمان الحفاظ على الربحية باستخدام COGS لمستخدم واحد، لكنه يتطلب مرة أخرى عملا إضافيا لقياس الاستهلاك لكل مستخدم.

المخاطر: مثل التسعير لكل مستخدم، هناك خطر من أن تؤثر أنماط الاستهلاك المختلفة للمستخدمين الفرديين على ربحيتك. مقارنة بالتسعير لكل مستخدم، تتمتع النماذج لكل مستخدم نشط بتدفق إيرادات أقل قابلية للتوقع. بالإضافة إلى ذلك، لا يقدم تسعير الخصم طريقة فعالة لتحفيز النمو.

تسعير لكل وحدة

لا يكون عدد المستخدمين، في العديد من الأنظمة، هو العنصر الذي له أكبر تأثير على COGS الكلي. على سبيل المثال، في الحلول الموجهة نحو الجهاز، يشار إليها أيضا باسم إنترنت الأشياء أو IoT، يكون غالبا لعدد الأجهزة التأثير الأكبر على COGS. يمكن، في هذه الأنظمة، استخدام نموذج تسعير لكل وحدة، حيث يمكنك تحديد ماهية الوحدة، مثل الجهاز. اطلع على الرسم التخطيطي التالي.

بالإضافة إلى ذلك، تحتوي بعض الحلول على أنماط استخدام متغيرة للغاية، حيث يكون لعدد صغير من المستخدمين تأثير غير متناسق على COGS. على سبيل المثال وفي الحل الذي يباع لتجار التجزئة التقليديين، قد يكون نموذج التسعير لكل متجر مناسبا.

مزايا: في الأنظمة التي لا يكون فيها للمستخدمين الفرديين تأثير كبير على COGS، فإن التسعير لكل وحدة هو طريقة أفضل لتمثيل حقيقة كيفية توسع النظام والتأثير الناتج على COGS. كما يمكن أن يحسن المحاذاة إلى أنماط الاستخدام الفعلية للعميل. بالنسبة للعديد من حلول IoT حيث يُنشئ كل جهاز كمية استهلاك قابلة للتنبؤ بها وثابتة، يمكن أن يكون هذا نموذجا فعالا لتوسيع نطاق نمو الحل لديك.

التعقيد والتكلفة التشغيلية: من السهل وبشكل عام، تنفيذ التسعير لكل وحدة ويكون له تكلفة تشغيلية منخفضة إلى حد ما. ومع ذلك، يمكن أن تصبح التكلفة التشغيلية أعلى إذا كنت بحاجة إلى تمييز الاستخدام وتتبعه باستخدام وحدات فردية مثل الأجهزة أو متاجر البيع بالتجزئة. يساعدك قياس الاستهلاك لكل وحدة على ضمان الحفاظ على الربحية، حيث يمكنك تحديد COGS لوحدة فردية.

المخاطر: مخاطر نموذج التسعير لكل وحدة مشابهة للتسعير لكل مستخدم. قد تعني أنماط الاستهلاك المختلفة من قبل بعض الوحدات أنك قللت من الربحية، مثل ما إذا كانت بعض الأجهزة أو المتاجر تستخدم الحل أكثر من غيرها.

تسعير مستند إلى مستوى الميزة والخدمة

يمكنك اختيار تقديم الحل مع مستويات مختلفة من الأداء الوظيفي ونقاط سعر مختلفة. قد تقدم، على سبيل المثال، سعرين شهريا بمعدل ثابت أو لكل وحدة، أحدهما عرض أساسي ومجموعة فرعية من الميزات المتوفرة، والآخر يقدم المجموعة الشاملة من ميزات الحل. اطلع على الرسم التخطيطي التالي.

قد يقدم هذا النموذج أيضا اتفاقيات مختلفة على مستوى الخدمة لمستويات مختلفة. قد يوفر المستوى الأساسي، على سبيل المثال، وقت تشغيل بنسبة 99.9٪، بينما قد يقدم المستوى المتميز 99.99٪. يمكن تنفيذ اتفاقية مستوى الخدمة الأعلى (SLA) باستخدام الخدمات والميزات التي تمكن أهداف قابلية الوصول العالية.

على الرغم من أن هذا النموذج يمكن أن يكون مفيدا تجاريا، فإنه يتطلب ممارسات هندسية مدروسة للعمل بشكل جيد. يمكن أن يكون هذا النموذج فعالا للغاية مع مراعاة متأنية.

مزايا: غالبا ما يكون التسعير المستند إلى الميزات جذابا للعملاء حيث يمكنهم تحديد المستوى استنادا إلى مجموعة الميزات أو مستوى الخدمة الذي يحتاجون إليه. كما يوفر لك مسارا واضحا لإعادة بيع عملائك بميزات إضافية أو مرونة أعلى لأولئك الذين يحتاجون إليها.

التعقيد والتكلفة التشغيلية: يمكن أن تكون نماذج التسعير المستندة إلى الميزات معقدة في التنفيذ، حيث تتطلب أن يكون الحل على دراية بالميزات المتوفرة في كل مستوى سعري. يمكن أن تكون تبديلات الميزات طريقة فعالة لتوفير الوصول إلى مجموعات فرعية محددة من الوظائف لكن يتطلب هذا صيانة مستمرة. أيضا، تزيد تبديلات الميزة من الحمل لضمان جودة عالية، لأنه سيكون هناك المزيد من مسارات التعليمات البرمجية للاختبار. قد يتطلب تمكين أهداف توفر الخدمة الأعلى في بعض المستويات تعقيدا هيكليا إضافيا لضمان استخدام المجموعة الصحيحة من البنية الأساسية لكل مستوى، وقد تزيد هذه العملية من التكلفة التشغيلية للحل.

المخاطر: يمكن أن تصبح نماذج التسعير المستندة إلى الميزات معقدة ومربكة في حالة وجود عدد كبير جدا من المستويات أو الخيارات. بالإضافة إلى ذلك، يمكن أن تؤدي المصاريف الإضافية المضمنة في ميزات التبديل ديناميكيا إلى إبطاء معدل تقديم ميزات إضافية.

تسعير الاشتراك المجاني

قد تختار تقديم مستوى مجاني من الخدمة لديك مع وظائف أساسية ودون ضمانات على مستوى الخدمة. يمكنك بعد ذلك تقديم مستوى منفصل مدفوع بميزات إضافية واتفاقية رسمية على مستوى الخدمة (كما هو موضح في الرسم التخطيطي التالي).

يمكن أيضا تقديم المستوى المجاني كإصدار تجريبي محدود المدة وقد يتمتع للعملاء خلال الفترة التجريبية بإتاحة وظائف كاملة أو محدودة. يشار إلى ذلك بنموذج الاشتراك المجاني وهو ملحق فعال لنموذج التسعير المستند إلى الميزات.

مزايا: من السهل للغاية تسويق حل مجاني.

التعقيد والتكلفة التشغيلية: تصدر جميع المخاوف بشأن التعقيد والتكلفة التشغيلية من نموذج التسعير المستند إلى الميزات. ومع ذلك، يجب أيضا مراعاة التكلفة التشغيلية المتضمنة في إدارة المستأجرين المجانيين. قد يجب عليك ضمان إلغاء حساب المستأجرين التالفين أو إزالتهم، ويجب أن يكون لديك نهج استبقاء واضح للمستأجرين المجانيين بشكل خاص. عند ترقية مستأجر إلى مستوى مدفوع، قد تحتاج إلى نقل المستأجر بين خدمات Azure، للحصول على اتفاقيات مستوى الخدمة أعلى. سيكون من المهم أيضا الاحتفاظ ببيانات المستأجر وتكوينه، عند الانتقال إلى مستوى مدفوع.

المخاطر: يجب عليك ضمان توفير ROV عالي بشكل كاف للمستأجرين لمراعاة التبديل إلى مستوى مدفوع. بالإضافة إلى ذلك، يجب تغطية تكلفة توفير الحل للعملاء على المستوى المجاني بواسطة هامش الربح ممن هم في المستويات المدفوعة.

تكلفة تسعير البضائع المبيعة

قد تختار تسعير الحل حيث يدفع كل مستأجر فقط تكلفة تشغيل حصته من خدمات Azure، دون هامش ربح إضافي. يستخدم هذا النموذج - الذي يسمى أيضا المرور من خلال التكلفة أو التسعير - في بعض الأحيان للحلول متعددة المستأجرين التي لا تهدف إلى أن تكون مركزا للربح.

نموذج تكلفة البضائع المبيعة مناسب تماما للحلول متعددة المستأجرين المخصصة داخليا. تتوافق كل وحدة تنظيمية مع مستأجر ويجب توزيع تكاليف موارد Azure بينها. قد يكون من المناسب أيضا عند الحصول على إيرادات من مبيعات المنتجات والخدمات الأخرى التي تستهلك أو تزيد من الحل متعدد المستأجرين.

الفوائد: نظرا لأن هذا النموذج لا يتضمن أي هامش إضافي للربح، ستكون التكلفة للمستأجرين أقل.

التعقيد والتكلفة التشغيلية: وعلى غرار نموذج الاستهلاك، تعتمد تكلفة تسعير البضائع المبيعة على قياسات دقيقة للاستخدام وعلى تقسيم هذا الاستخدام حسب المستأجر. يمكن أن يكون تتبع الاستهلاك صعبا خاصة في حل يتضمن العديد من المكونات الموزعة. تحتاج إلى الاحتفاظ بسجلات استهلاك مفصلة للفوترة والتدقيق بالإضافة إلى توفير طرق للعملاء للوصول إلى بيانات الاستهلاك الخاصة بهم.

بالنسبة للحلول متعددة المستأجرين المخصصة داخليا، قد يقبل المستأجرون تقديرات التكلفة التقريبية ولديهم متطلبات تدقيق الفوترة بشكل أكثر راحة. تقلل هذه المتطلبات المريحة من تعقيد وتكلفة تشغيل الحل لديك.

المخاطر: يمكن أن تحفز تكلفة تسعير البضائع المبيعة المستأجرين على تقليل استخدامهم النظام لتقليل التكاليف. ومع ذلك، نظرا لاستخدام هذا النموذج للتطبيقات التي ليست مراكز ربح، فقد لا يكون هذا مصدر قلق.

تسعير معدل ثابت

يمكنك، في هذا النموذج، فرض معدل ثابت على المستأجر للوصول إلى الحل لفترة زمنية محددة. يطبق نفس التسعير بغض النظر عن مقدار استخدامهم للخدمة أو عدد المستخدمين أو عدد الأجهزة التي تتصل بها أو أي مقياس آخر. اطلع على الرسم التخطيطي التالي.

هذا هو أبسط نموذج قابل للتنفيذ ولفهم للعملاء، وغالبا ما يطلبه عملاء المؤسسة. ومع ذلك، يمكن أن يصبح بسهولة غير مربحا إذا كنت بحاجة إلى مواصلة إضافة ميزات جديدة أو إذا زاد استهلاك المستأجر دون أي إيرادات إضافية.

مزايا: تسعير المعدل الثابت سهل البيع ويسهل على العملاء فهمه ووضع ميزانية له.

التعقيد والتكلفة التشغيلية: يمكن أن تكون نماذج التسعير ذات المعدل الثابت سهلة التنفيذ لأن عملاء الفوترة لا يطلبون أي قياس أو تتبع استهلاك. إلا أنه يوصى، على الرغم من أنه ليس ضروريا، بقياس الاستهلاك لكل مستأجر لضمان قياس COGS بدقة وضمان الحفاظ على الربحية لديك.

المخاطر: إذا كان لديك مستأجرون يستخدمون الحل بشكل كبير، فمن السهل أن يصبح نموذج التسعير هذا غير مربح.

تسعير الخصم

بمجرد تحديد نموذج التسعير، قد تختار تنفيذ استراتيجيات تجارية لتحفيز النمو من خلال تسعير الخصم. يمكن استخدام تسعير الخصم مع نماذج تسعير الاستهلاك ولكل مستخدم ولكل وحدة.

إشعار

لا يتطلب تسعير الخصم عادة اعتبارات هيكلية بخلاف إضافة دعم لبنية فوترة أكثر تعقيدا. مناقشة كاملة حول الفوائد التجارية للخصم خارج نطاق هذه الوثيقة.

تتضمن أنماط تسعير الخصم الشائعة ما يلي:

• تسعير ثابت. لديك نفس التكلفة لكل مستخدم أو وحدة أو مقدار استهلاك بغض النظر عن مقدار ما يتم شراؤه أو استهلاكه. هذا هو أبسط نهج. ومع ذلك، قد يشعر العملاء الذين يستخدمون الحل بكثافة أنه يجب عليهم الاستفادة من وفورات التوسع بالحصول على خصم.
• التسعير التنازلي. نظرا لأن العملاء يشترون أو يستهلكون المزيد من الوحدات، فأنت تقلل التكلفة لكل وحدة. هذا أكثر جاذبية من الناحية التجارية للعملاء.
• تسعير الخطوة. يمكنك تقليل التكلفة لكل وحدة، حيث يشتري العملاء المزيد. ومع ذلك، يمكنك تنفيذ ذلك في تغييرات الخطوة استنادا إلى نطاقات الكمية المحددة مسبقا. قد تفرض، على سبيل المثال، سعرا أعلى على أول 100 مستخدم، ثم سعر أقل بدءا من المستخدم 101 إلى المستخدم 200، ثم سعر أقل مرة أخرى بعد ذلك. يمكن أن يكون هذا أكثر ربحا.

يوضح الرسم التخطيطي التالي أنماط التسعير هذه.

خصومات البيئة غير الإنتاجية

يجب على العملاء، في كثير من الحالات، الوصول إلى بيئة غير إنتاجية يمكنهم استخدامها للاختبار أو التدريب أو لإنشاء وثائقهم الداخلية الخاصة. عادة ما يكون للبيئات غير الإنتاجية متطلبات وتكاليف استهلاك أقل للتشغيل. على سبيل المثال، لا تخضع غالبا البيئات غير الإنتاجية لاتفاقيات مستوى الخدمة (SLAs)، وقد يتم تعيين حدود المعدل بقيم أقل. قد تراعي أيضا التوسع التلقائي الأكثر تقييدا على خدمات Azure.

وبالمثل، يتوقع العملاء غالبا أن تكون البيئات غير الإنتاجية أرخص بكثير من بيئات الإنتاج لديهم. هناك العديد من البدائل التي قد تكون مناسبة عند توفير بيئات غير إنتاجية:

• قدم مستوى اشتراك مجانيمثل ما تنفذه بالفعل للعملاء المدفوعين. وينبغي رصد ذلك بعناية فقد تنشئ بعض المؤسسات العديد من بيئات الاختبار والتدريب، مما سيستهلك موارد إضافية للتشغيل.

  إشعار

  عادة ما تكون التجارب المجانية المحدودة زمنيا باستخدام مستويات الاشتراك المجاني غير مناسبة لبيئات الاختبار والتدريب. يحتاج العملاء عادة إلى بيئات غير الإنتاجية لتكون متاحة طوال مدة خدمة الإنتاج.

• قدم مستوى اختبار أو تدريب للخدمة لديك مع حدود استخدام أقل. يمكنك اختيار تقييد إتاحة هذا المستوى للعملاء الذين لديهم مستأجر مدفوع موجود.
• تقديم أسعار مخفضة لكل مستخدم أو لكل مستخدم نشط أو لكل وحدة للمستأجرين غير المنتجين مع اتفاقية مستوى خدمة أقل أو بدونها.
• بالنسبة للمستأجرين الذين يستخدمون تسعير المعدل الثابت، قد يتم التفاوض على البيئات غير الإنتاجية كجزء من الاتفاقية.

إشعار

لا يمثل عادة التسعير المستند إلى الميزات خيارا جيدا للبيئات غير الإنتاجية، ما لم تكن الميزات المعروضة هي نفس ما تقدمه بيئة الإنتاج. وذلك لأن المستأجرين سيرغبون عادة في اختبار وتوفير التدريب على جميع الميزات نفسها المتوفرة لهم في الإنتاج.

نماذج تسعير غير مربحة

يكلفك نموذج التسعير غير المربح تكلفة أكبر لتقديم الخدمة أكثر من الإيرادات التي تحققها. على سبيل المثال، قد تفرض معدلا ثابتا على كل مستأجر دون أي حدود للخدمة لديك، ويمكنك بعد ذلك إنشاء الخدمة باستخدام موارد Azure المستندة إلى الاستهلاك ودون حدود استخدام لكل مستأجر. قد تتعرض، في هذه الحالة، لخطر إفراط استخدام المستأجرين للخدمة لديك مما يجعل خدمتهم غير مربحة.

ترغب في تجنب نماذج التسعير غير المربحة بشكل عام. ومع ذلك، هناك حالات قد تختار فيها اعتماد نموذج تسعير غير مربح بما في ذلك:

• يتم تقديم خدمة مجانية لتمكين النمو.
• يتم تنفيذ عمليات تدفق إيرادات إضافية بواسطة الخدمات أو الميزات الإضافية.
• تقدم استضافة مستأجر محدد قيمة تجارية أخرى مثل استخدامها كمستأجر إرساء في سوق جديدة.

في حالة إنشاء نموذج تسعير غير مربح دون قصد، هناك بعض الطرق للتخفيف من المخاطر المرتبطة بها بما في ذلك:

• حدد استخدام الخدمة من خلال حدود الاستخدام.
• اطلب استخدام حجز القدرة الإنتاجية.
• اطلب من المستأجر الانتقال إلى ميزة أو مستوى خدمة أعلى.

نماذج التسعير غير الآمنة

عند تنفيذ نموذج تسعير للحل، سيتعين عليك عادة وضع افتراضات حول كيفية استخدامه. إذا تبين أن هذه الافتراضات غير صحيحة أو إذا تغيرت أنماط الاستخدام بمرور الوقت، فقد يصبح نموذج التسعير غير مربح. تُعرف نماذج التسعير المعرضة لخطر أن تصبح غير مربحة باسم نماذج التسعير غير الآمنة. على سبيل المثال، إذا كنت تعتمد نموذج تسعير يتوقع من المستخدمين أن يحددوا بأنفسهم المبلغ الذي يستخدمونه للحل، فربما تكون قد نفذت نموذج تسعير غير آمن.

ستضيف معظم حلول SaaS ميزات جديدة بانتظام. وهذا يزيد من ROV للمستخدمين، مما قد يؤدي أيضا إلى زيادة في القيمة التي يستخدمها الحل. قد يتسبب هذا في أن يصبح الحل غير مربح، إذا كان استخدام الميزات الجديدة يدفع إلى الاستخدام لكن نموذج التسعير لا يراعي ذلك.

على سبيل المثال، إذا قدمت ميزة تحميل فيديو جديدة إلى الحل والذي يستخدم موردا يستند إلى الاستهلاك، وكان استيعاب المستخدم للميزة أعلى من المتوقع، فيجب مراعاة مجموعة مكونة من حدود الاستخدام وأسعار الميزة ومستوى الخدمة.

حدود الاستخدام

تمكنك حدود الاستخدام من تقييد استخدام الخدمة لمنع نماذج التسعير لديك من أن تصبح غير مربحة، أو لمنع مستأجر واحد من استهلاك قدر غير متناسب من القدرة الإنتاجية للخدمة. يمكن أن يكون هذا مهما بشكل خاص في الخدمات متعددة المستأجرين، حيث يمكن لمستأجر واحد التأثير على تجربة المستأجرين الآخرين من خلال الإفراط في استهلاك الموارد.

إشعار

من المهم إعلام عملائك بأنك تطبق حدود الاستخدام. في حالة تطبيق حدود الاستخدام دون إخطار عملائك بهذا الحد، فسينتج عن ذلك عدم رضا العملاء. وهذا يعني أنه من المهم تحديد وتخطيط حدود الاستخدام مسبقا. يجب أن يكون الهدف هو التخطيط للحد، ثم إعلام العملاء بالحدود قبل أن تصبح ضرورية.

يتم غالبا استخدام حدود الاستخدام مع التسعير على مستوى الميزات والخدمة، لتوفير قدر أكبر من الاستخدام في مستويات أعلى. تستخدم الحدود أيضا بشكل شائع لحماية المكونات الأساسية التي ستتسبب في اختناقات في النظام أو مشكلات في الأداء، إذا كانت مستهلكة بشكل مفرط.

حدود السعر

تتمثل إحدى الطرق الشائعة لتطبيق حد الاستخدام في إضافة حدود المعدل إلى APIs أو إلى وظائف تطبيق محددة. ويشار إلى هذا أيضا باسم التقييد. تمنع حدود المعدل الاستخدام المفرط بشكل مستمر. غالبا ما يتم استخدامها للحد من عدد الاستدعاءات إلى واجهة برمجة التطبيقات، على مدى فترة زمنية محددة. على سبيل المثال، قد يتم استدعاء واجهة برمجة تطبيقات 20 مرة فقط في الدقيقة، وسترجع خطأ HTTP 429 إذا تم استدعاؤها بشكل متكرر أكثر من ذلك.

تتضمن بعض الحالات، حيث يتم غالبا استخدام تحديد المعدل، ما يلي:

• واجهات برمجة تطبيقات REST.
• مهام غير متزامنة.
• المهام غير الحساسة للوقت.
• إجراءات تتطلب تكلفة عالية لتنفيذها.
• عملية إنشاء التقرير.

يمكن أن يزيد تنفيذ تحديد المعدل من تعقيد الحل، ولكن يمكن لخدمات مثل Azure API Management أن تجعل هذا الأمر أكثر بساطة بتطبيق نهج حد المعدل.

دورة حياة نموذج التسعير

تتمتع نماذج التسعير، مثل أي جزء آخر من الحل لديك، بدورة حياة. حيث يتطور التطبيق بمرور الوقت، قد تحتاج إلى تغيير نماذج التسعير. قد ينتج ذلك عن تغيير احتياجات العملاء أو المتطلبات التجارية أو التغييرات في الوظائف داخل التطبيق لديك. تتضمن بعض تغييرات دورة حياة التسعير الشائعة ما يلي:

• إضافة نموذج تسعير جديد تماما. على سبيل المثال، إضافة نموذج تسعير استهلاك إلى حل يقدم حاليا نموذج معدل ثابت.
• إيقاف نموذج تسعير موجود.
• إضافة مستوى إلى نموذج تسعير موجود.
• إيقاف مستوى في نموذج تسعير موجود.
• تغيير حدود الاستخدام لميزة في نموذج التسعير.
• إضافة ميزات أو إزالتها من نموذج تسعير على مستوى الميزات والخدمة.
• التغيير من نموذج تجاري متاجرة عمل-مستهلك (B2C)، إلى نموذج تجاري متاجرة عمل-عمل (B2B). يتطلب هذا التغيير هياكل تسعير جديدة للعملاء التجاريين لديك.

عادة ما يكون تنفيذ وإدارة العديد من نماذج التسعير المختلفة في وقت واحد أمرا معقدا. كما أنه مربك لعملائك. لذلك من الأفضل تنفيذ نموذج واحد أو نموذجين فقط مع عدد قليل من المستويات. وهذا يجعل الحل أكثر قابلية للوصول وسهولة للإدارته.

إشعار

يجب اختبار نماذج التسعير ووظائف الفوترة بشكل مثالي باستخدام الاختبار التلقائي تماما مثل أي جزء آخر من النظام لديك. كلما كانت نماذج التسعير أكثر تعقيدا، كان هناك حاجة إلى المزيد من الاختبارات وبالتالي ستزيد تكلفة التطوير والميزات الجديدة.

عند تغيير نماذج التسعير، ستحتاج إلى مراعاة العوامل التالية:

• هل سيرغب المستأجرون في الترحيل إلى النموذج الجديد؟
• هل من السهل على المستأجرين الترحيل إلى النموذج الجديد؟
• هل تعرض نماذج التسعير الجديدة خدمتك للخطر؟ على سبيل المثال، هل تقوم بإزالة حدود المعدل التي تحمي الموارد الهامة حاليا من الإفراط في الاستخدام؟
• هل يحتفظ المستأجرون بمسار واضح للترحيل إلى نموذج التسعير الجديد؟
• كيف ستمنع المستأجرين من استخدام نماذج التسعير القديمة، حيث يمكنك إيقافها؟
• هل من المحتمل أن يتعرض المستأجرون إلى صدمة من الفاتورة (رد فعل سلبي على فاتورة غير متوقعة) عند تغيير نماذج التسعير؟
• هل تراقب أداء الخدمات واستخدامها لنماذج التسعير الجديدة أو المتغيرة حتى يمكنك ضمان استمرار الربحية؟
• هل يمكنك توصيل ROV لنماذج التسعير الجديدة بشكل واضح إلى المستأجرين الحاليين؟

المساهمون

تحتفظ Microsoft بهذه المقالة. وهي مكتوبة في الأصل من قبل المساهمين التاليين.

الكاتب الرئيسي:

• دانيال سكوت راينسفورد | الاستراتيجي التكنولوجي الشريك

مساهمون آخرون:

• بوهدان شيرشيك | مهندس عملاء أول، FastTrack لـAzure
• جون داونز | مهندس العملاء الرئيسي، FastTrack ل Azure
• تشاد كيتل | مهندس برامج رئيسي
• باولو سالفاتوري | مهندس العملاء الرئيسي، FastTrack for Azure
• Arsen Vladimirskiy | مهندس العملاء الرئيسي، FastTrack for Azure

لمشاهدة ملفات تعريف LinkedIn غير العامة، سجل الدخول إلى LinkedIn.

الخطوات التالية

ضع في اعتبارك كيفية قياس الاستهلاك من قبل المستأجرين في الحل لديك.