01 / START HERE
A useful way to approach it.
A three-person team choosing software needs to know which tasks a package covers, what the team might pay, and what still requires a trial. Public sources can establish published conditions; they do not show how the product performs in your working environment.
Use o1 to organize supplied documentation and pricing excerpts, or retrieve current material when signed-in web search is enabled. Build the comparison around your requirements before looking at vendor claims. The example uses fictional vendors and prices to demonstrate cost arithmetic; it is not a purchasing recommendation, supplier audit, or hands-on product review.
02 / THE PROCESS
Go from question to next step.
- 01
Write requirements before a shortlist
List the tasks your team must complete and distinguish essential requirements from preferences. Specify user count, storage, external collaboration, data export, and any required workflow. Define a disqualifying condition such as an unsupported export format. A product with many attractive features can still fail the one task you actually need.
- 02
Read appropriate public documentation
Inspect feature guides, pricing pages, support descriptions, and published terms for the relevant package. Keep the access date and exact condition beside each finding. An integration logo may indicate availability without explaining supported actions or setup. Mark unclear implementation details as questions rather than assuming a complete connection between your tools.
- 03
Normalize the cost scenario
Choose a comparison period and currency, then account for seats, minimum commitments, required add-ons, and known usage assumptions. Show annual commitment separately from monthly cash outlay. Treat taxes, negotiated rates, and unpublished charges as unresolved unless you have reliable evidence. Ask the assistant to show its calculation, then check each input and total.
- 04
Score fit without hiding uncertainty
Apply criteria you chose before viewing the results. Record documented fit, partial fit, or unknown rather than automatically awarding points for missing information. Explain any weighting and show which requirement could change the shortlist. An elaborate numeric score can conceal weak evidence, so retain the source and reason beside every assessment.
- 05
Prepare a trial and clarification plan
Choose a small real task to test yourself and list questions for the vendor. Check onboarding effort, permission boundaries, export usability, and the workflow most likely to fail. Update the comparison after those checks. Public-source research creates a shortlist; it does not establish security certification validity, service reliability, or suitability for every team.
03 / YOUR STARTING POINT
A prompt you can make your own.
Replace the bracketed fields. Add only information you have permission to share. This is a reusable text prompt; it does not run a task from this page.
Compare {{vendors}} for {{team}} doing {{tasks}}. Essential requirements: {{requirements}}. Use these dated public documentation and price excerpts: {{sources}}. Show package, documented fit, limitations, evidence pointer, and unknowns. Calculate {{period}} cost for {{seats}} seats under {{usage}}, including stated mandatory add-ons and minimums. Label all assumed quantities; do not invent current prices or negotiated terms. Separate public-source findings from hands-on questions. Finish with a shortlist rationale and five checks I should perform in a trial.04 / SEE THE SHAPE OF IT
Illustrative three-person software comparison
Fictional vendors and prices authored for this example. Neither product has been tested and no live pricing was retrieved.
| Vendor / requirement | Fictional monthly scenario | Open question |
|---|---|---|
| Cedar: three seats | 3 × $15 = $45 | Does every collaborator need a seat? |
| Cedar: required storage | $45 + $8 = $53 | Is the assumed storage amount enough? |
| Birch: team package | $60 for up to five seats | Which export options are included? |
| Both: essential workflow | Public guides describe different setup steps | Complete the same trial task yourself |
The arithmetic is transparent, but a lower modeled cost does not settle workflow fit. The unanswered essential requirement deserves a trial before a purchase.
05 / KEEP YOUR JUDGMENT
What to watch before you use it.
Comparing headline prices
A per-user number and a team package are different units. Compare the same user count, period, and required features.
Calling documentation a product test
Say what the vendor publishes. Reserve performance conclusions for checks you actually performed and describe their conditions.
Giving unknowns a passing score
An undocumented requirement remains unresolved. Do not let a default number make a candidate appear qualified.
06 / THE FINAL PASS
A little review goes a long way.
Your checks stay on this page. They do not approve or run a task.
07 / GOOD QUESTIONS
Before you begin.
Can this determine the best software for my team?
It can make a shortlist more defensible, but suitability depends on your priorities and actual workflow. Review the evidence, perform relevant trial tasks, and resolve essential unknowns before deciding.
Should I use a weighted decision matrix?
Use one when the criteria and weights reflect your team's priorities. Keep the reasons and evidence visible. If a mandatory requirement is unknown or unmet, do not allow a strong total score on optional features to hide that issue.
How do I compare monthly and annual offers?
Convert both to the same comparison period while retaining the commitment and payment schedule. An annual average is not necessarily a month-to-month purchase option. Record the terms and any assumed renewal conditions beside the calculation.