What this template is for
Vendor evaluations are how teams decide which third-party tools to depend on for years. Get the decision right and you save time; get it wrong and you spend the next two years migrating off whatever you picked while still paying for it.
This template enforces a discipline most evaluations skip:
- Required fields on the create screen - business driver, requirements, scoring criteria, security review status, budget, deadline. Writing requirements before seeing demos is the single biggest factor in making a defensible decision; the template makes it required.
- STM-created evaluation sub-tasks - requirements, shortlist, demos, POC, security review, reference checks, recommendation, decision. Without the security review and reference check sub-tasks, teams skip them under deadline pressure and regret it later.
When to use it
Use this template for vendor decisions with multi-quarter commitment, customer-data handling, or non-trivial spend. Also use it when the decision will be re-asked in 18 months - having the written evaluation on hand prevents ‘wait, why did we pick this?’ from costing another month.
Don’t use this template for small tooling choices where one engineer can decide in an afternoon. The overhead of formal evaluation is the wrong tax for low-stakes choices.
Fields to add to your Jira create screen
These are the fields a project admin should make sure exist on the Create Issue screen for this issue type (Project settings → Screens). Without these on the screen, reporters can't provide the information triage needs - and STM can't reference them either.
| Field | Example value | Required |
|---|---|---|
Summary | Evaluate APM vendors: replace existing observability stack by Q4 | Yes |
Business Driver (custom) | Why we're evaluating - cost, capability gap, end-of-life | Yes |
Evaluation Owner | @engineer.who.owns.the.decision | Yes |
Sponsor | @director.or.vp.who.approves | No |
Requirements (custom) | Must-have / Nice-to-have / Out-of-scope - written before vendors are seen | Yes |
Candidate Vendors (custom) | Shortlist with brief rationale for inclusion | No |
Scoring Criteria (custom) | Weighted criteria - capability, cost, security, support, lock-in | Yes |
Security Review Status (custom) | Required for any vendor handling customer data | No |
Budget Range (custom) | Approved spend range | No |
Decision Deadline (custom) | When the decision must be made | Yes |
Recommendation (custom) | Filled in at end of evaluation | No |
Note on custom fields. STM currently supports up to 5 custom fields per template. You can add as many custom fields as you like to your Jira Create Issue screen - the 5-field limit only applies if you want STM to set or update those custom fields itself.
Sub-tasks STM creates automatically
Build an STM sub-task template containing the items below, then wire it to an On Create Issue Executor scoped to this issue type. Whenever a new issue of this type is created in the project, STM creates the full sub-task set in one step - with assignee, due date, and components inherited from the parent unless you override them.
- Write requirements with stakeholders - must-have / nice-to-have / out-of-scope
- Identify and shortlist candidate vendors (typically 3-5)
- Request demos and trial access for shortlisted vendors
- Run a proof of concept on the top 2 candidates against real use cases
- Security review for vendors handling sensitive data
- Reference checks with similar-sized customers
- Write recommendation with scoring breakdown and trade-offs
- Sponsor decision and contract negotiation handoff
Common questions
When does a vendor evaluation need its own Jira ticket vs a regular task?
When the decision involves multi-quarter commitment, customer-data handling, integration work, or non-trivial spend. A $20/month tool one engineer picks doesn't need a formal evaluation. A $100k/year platform that 50 engineers will depend on does. The middle is judgement, but err toward formal evaluation when in doubt - skipping diligence is expensive when it goes wrong.
What should requirements look like for a Jira vendor evaluation?
Written before seeing any vendor demo. Must-have / nice-to-have / out-of-scope, with specific testable criteria ('supports OIDC SSO' not 'good security'). Requirements written after a vendor demo end up reverse-engineered from what the favoured vendor already does, which defeats the purpose of evaluation.
Should vendor evaluations include a security review?
Always, for any vendor that will handle customer data, code, or production access. The security review is a sub-task that gates the recommendation. Skipping security review and finding out later that the vendor doesn't support your IdP or doesn't have SOC 2 is the most expensive way to discover those facts.
Who makes the final vendor decision?
The evaluation owner recommends; the sponsor decides; the team consulted gets a voice. Without this clarity, vendor decisions get re-litigated for months. Put 'sponsor' on the ticket explicitly so it's clear which exec is on the hook for the decision when it's made.
Automate the sub-tasks with STM
STM Issue Templates saves the sub-task list above as a reusable template and creates them on every new issue of this type - via an Executor on issue creation, on status transition, or triggered manually from the issue's "Create bulk sub-tasks" menu. STM does not change the parent issue's create screen (that's a Jira project-settings job) but it removes the manual work of creating the sub-tasks every time.
Try STM on the Atlassian Marketplace ↗ See how STM templates are built →