استخدم هذا الـ Prompt من AI لتحويل النقاشات الفوضوية حول الـ vendor إلى مصفوفة قرارات مرجحة
Why this prompt matters
Teams waste weeks on decisions that feel data-driven but are really just opinion contests with prettier slides. A strong weighted matrix forces the hidden assumptions into the open, shows where tradeoffs really are, and gives decision-makers a record they can defend later if the choice is questioned.
What we use it for
You have to choose between three vendors before a leadership meeting tomorrow, but every stakeholder is optimizing for something different. One person wants the cheapest option, another wants security and compliance, and the team that has to implement it cares most about integrations and migration pain. This Prompt turns a messy argument into a structured recommendation you can actually present.
Prompt
Role: Act as a senior strategy analyst and procurement advisor who helps teams make defensible decisions under time pressure. Context: I need to compare multiple options for a business decision such as software vendors, agencies, tools, platforms, hiring choices, or internal project directions. I do not want a vague pros-and-cons list. I need a weighted decision matrix that forces explicit tradeoffs and produces a recommendation I can defend in a meeting. Task: Review the options I provide, the evaluation criteria, and any constraints. Build a weighted decision matrix, score each option against each criterion, explain the reasoning behind the scores, identify the biggest tradeoffs, and recommend the best option. If my criteria are weak, overlapping, or missing something important, fix the framework before scoring. Constraints: - Do not give every option similar scores just to appear balanced. - Challenge bad criteria, duplicated criteria, or unrealistic weighting. - If important information is missing, state the assumption you are making. - Separate must-have requirements from nice-to-have preferences. - Consider implementation risk, switching cost, and long-term operational impact, not just headline features. - If one option wins on paper but creates major execution risk, call that out clearly. - Keep the explanation practical and specific, not academic. - Preserve important business terms such as ROI, API, SLA, compliance, security, TCO, and integration when relevant. Output Format: 1. Decision summary in 3 to 5 bullet points 2. Clean weighted decision matrix table 3. Score rationale for each option by criterion 4. Biggest tradeoffs and risks 5. Recommended option with confidence level 6. What would change the recommendation 7. Executive-ready 5 sentence version for stakeholders Inputs: - Decision to make: [DESCRIBE THE DECISION] - Options: [LIST THE OPTIONS] - Criteria and suggested weights: [LIST THEM OR ASK THE MODEL TO PROPOSE THEM] - Non-negotiables: [MUST-HAVE REQUIREMENTS] - Constraints: [BUDGET, TIMELINE, TEAM SIZE, COMPLIANCE, ETC.] - Stakeholders: [WHO NEEDS TO AGREE] - Known concerns or politics: [OPTIONAL]
Result
1. Decision summary - Vendor B is the strongest overall choice because it balances security, integration quality, and implementation speed better than the alternatives. - Vendor A is cheaper upfront, but its weaker API coverage and limited reporting would create more operational friction within six months. - Vendor C has the strongest feature set on paper, but the migration timeline and higher services dependency increase delivery risk for a mid-sized team. - If budget pressure becomes the dominant constraint, Vendor A becomes more attractive, but only if the company accepts more manual work and lower automation headroom.
2. Weighted decision matrix Criteria: Security and compliance (25), integration quality (20), total cost of ownership (15), implementation speed (15), reporting and admin control (10), vendor support and SLA (10), scalability for the next 24 months (5) - Vendor A: 72/100 - Vendor B: 84/100 - Vendor C: 79/100
3. Score rationale Vendor A scored well on cost and acceptable on implementation speed because the license is the lowest and procurement is straightforward. It lost points on integration quality because it relies on batch syncs instead of deeper API coverage, which would increase manual reconciliation for operations. It also scored lower on reporting because several dashboards would need custom exports.
Vendor B scored highest because it is the most balanced option. Its API coverage is mature, security documentation is enterprise-ready, and the admin controls are strong enough for the compliance team without creating heavy rollout overhead. The implementation path is not the cheapest, but it is realistic for the current team and does not require specialist consultants.
Vendor C scored highest on raw features and future scalability, but the migration plan is the main issue. It requires a longer deployment window, heavier services support, and more change management. That could still be the right choice for a larger organization, but it is a harder fit for a team that needs value in the next quarter.
4. Biggest tradeoffs and risks The main tradeoff is between lower short-term cost and lower long-term friction. Choosing Vendor A saves money now but increases operational drag later. Choosing Vendor C buys more upside but raises implementation risk. Vendor B is the best compromise because it avoids both extremes.
5. Recommended option with confidence level Recommend Vendor B with medium-high confidence. It is not the cheapest or the most ambitious option, but it best fits the current operating constraints and stakeholder needs.
6. What would change the recommendation If the budget cap drops by another 20 percent, revisit Vendor A. If the company plans a major global rollout in the next 12 months and can fund a heavier implementation, reconsider Vendor C.
7. Executive-ready version Vendor B is the best overall choice because it gives the company the strongest balance of security, integration quality, and rollout speed. Vendor A is cheaper but would create more manual process pain. Vendor C is powerful but harder to implement on the current timeline. The recommendation is based on weighted criteria rather than headline features alone. Unless budget or strategic scope changes materially, Vendor B is the most defensible decision.
بعض أغلى الأخطاء التجارية لا تأتي من نقص البيانات. بل تأتي من التظاهر بأن القرار موضوعي في حين أن المفاضلات الحقيقية لم تُكتب بوضوح. تقارن الفرق بين الـ vendors والأدوات والخيارات الداخلية في اجتماعات لا تنتهي، لكن النقاش غالبًا ما يتحول إلى شخصيات، أو سياسات، أو من يتحدث بثقة أكبر.
هذا الـ Prompt صُمم لإصلاح ذلك. إنه يجبر النموذج على التصرف كمحلل استراتيجي بدلاً من مساعد عصف ذهني. بدلاً من إنتاج قائمة عامة بالإيجابيات والسلبيات، فإنه يبني مصفوفة قرارات مرجحة، ويتحدى المعايير الضعيفة، ويفصل بين الأمور غير القابلة للتفاوض والتفضيلات، ويشرح لماذا يجب أن يفوز خيار واحد تحت القيود المذكورة.
الهيكل مهم. يخبر الـ Role النموذج أن يفكر كشخص عليه الدفاع عن توصية، وليس فقط توليد الأفكار. يوضح الـ Context أن الهدف هو خيار عملي تجاري، وليس مقارنة غامضة. يصر الـ Task على تقييم صريح، ومبرر التقييم، وتحليل المفاضلات، وتوصية. أما الـ Constraints فهي حيث يصبح الـ Prompt مفيدًا حقًا: فهي تمنع النموذج من تسوية كل خيار في نفس الإجابة، وتجبره على مراعاة مخاطر التنفيذ، وتكلفة التحول، والتأثير التشغيلي طويل المدى.
هذا هو النوع من الـ Prompt الذي يساعد عندما تختار الفرق نظام CRM، أو أداة analytics، أو AI vendor، أو منصة security، أو وكالة تسويق، أو اتجاه مشروع داخلي. إنه مفيد بشكل خاص عندما يسحب أصحاب المصلحة في اتجاهات مختلفة ويحتاج مالك القرار إلى إطار يمكنه الصمود أمام التدقيق التنفيذي.
يظهر نموذج الإخراج القيمة الحقيقية. إنه لا يكتفي بتتويج فائز. بل يشرح لماذا الفائز هو الأقوى تحت القيود الحالية، وما المفاضلات التي يقبلها الفريق، وما التغيير في الافتراضات الذي سيقلب التوصية. وهذا يجعله أكثر قابلية لإعادة الاستخدام بكثير من جدول مقارنة لمرة واحدة.
إذا كنت تجلس بانتظام في اجتماعات قرار حيث يدعي الجميع أنهم يعتمدون على البيانات ولكن لا أحد يتفق على منطق التقييم، فهذا Prompt يستحق الحفظ. إنه يحول حجة ضبابية إلى إطار، وهذا غالبًا هو الفرق بين قرار سريع وأسبوع من النقاش الذي يمكن تجنبه.