The prompt
Score 10 of 10, Excellent
Use it when You need to compare tools against your must-haves, budget and integrations before booking demos.
- {{job_to_be_done}}
- {{team}}
- {{must_haves}}
- {{nice_to_haves}}
- {{budget}}
- {{current_tools}}
- {{requirements}}
- {{candidates}}
- {{vendor_info}}
Full prompt and why it works
Prompt
What the tool is for: {{job_to_be_done}} Who will use it: {{team}} Must-haves: {{must_haves}} Nice-to-haves: {{nice_to_haves}} Budget: {{budget}} Tools it must work with: {{current_tools}} Security, privacy or purchasing requirements: {{requirements}} Tools I am already considering: {{candidates}} Vendor information I have collected (pricing pages, feature lists, review notes), if any: """ {{vendor_info}} """ Task: Help me build a shortlist of software tools for the job above, so that I can book demos with the two or three most likely to fit instead of trialing ten. Format: 1. Requirements check: my must-haves restated as tests a demo could pass or fail. Turn vague ones into something checkable, for example "easy to use" into "a new team member can set up a project without training in under 10 minutes". 2. Comparison table of 3 to 6 tools with the columns Tool, Must-haves met (yes, no or unclear for each), Works with our tools, Price as stated, Biggest drawback, Source. Include the tools I am already considering. 3. Shortlist: the two or three to demo, with one sentence each on why. 4. Demo questions: five questions to ask every vendor, including one on exporting our data if we leave, one on what costs extra (such as single sign-on, more users or a higher support tier) and one on contract length and cancellation. 5. Ruled out: tools left off, with the reason in one line each. Requirements: - Prices, plans and features change often, and your knowledge may be out of date. Use the vendor information I pasted wherever it covers a point, and name it in the Source column. Mark anything from your general knowledge "(check)". Do not state a price that is not in my material; write "check current pricing" instead. - Include only tools you are confident exist and are still sold. Do not rank on features I did not ask for. - A tool that fails a must-have is ruled out, however strong it is otherwise. If you cannot tell whether a tool meets a must-have, mark it "unclear" rather than yes. - Keep it under 700 words plus the table, in plain language for a buyer who is not technical. The shortlist should be one I can defend to my manager: every tool on it meets every must-have as far as the evidence shows, and every "unclear" becomes a question for the demo. If my requirements conflict, for example the budget looks too low for tools with all the must-haves, say so plainly instead of stretching the facts.
Variables
- {{job_to_be_done}}
- The problem the tool should solve, for example "tracking client projects and billable hours".
- {{team}}
- Who will use it and how many, for example "12 people in two offices, mostly not technical".
- {{must_haves}}
- The requirements a tool has to meet to be considered, one per line.
- {{nice_to_haves}}
- Features that would help but are not essential, one per line. Write "none" if there are none.
- {{budget}}
- For example "under $15 per user per month" or "$5,000 a year".
- {{current_tools}}
- Systems it must connect to, such as your email, calendar, accounting software or single sign-on.
- {{requirements}}
- For example data stored in the EU, single sign-on or a security review. Write "none" if there are none.
- {{candidates}}
- Tools you already have in mind. Write "none" if you are starting fresh.
- {{vendor_info}}
- Text copied from vendors' pricing and feature pages, with the date you copied it. Write "none" if you have not collected any yet.
Why it works
- What to avoid. Prices and features from the model's memory are marked "(check)" and no price is stated unless you supplied it, because software pricing goes out of date quickly.
- What good looks like. A tool that fails one must-have is ruled out, and anything uncertain becomes a demo question, so the shortlist holds up when your manager asks why.
- An example. One worked example turns a vague requirement like "easy to use" into a test a demo can pass or fail.