Skip to content
KoshKramaniti

ChecklistFree templateAdded 29 Sep 2026

Decide which AI ideas to build, help with, or leave alone

Sort each AI idea into build, assist, keep with people, defer or reject, with a reason and a named owner.

Use it when A startup or SMB has a pile of AI ideas and needs a clear yes, no or not-now before anyone spends time or money.

Download template

It is a simple text file. Open it in any text editor, or paste it into ChatGPT, Claude or Gemini and ask for help filling it in.

How to use it

  1. Gather the ideas that are already floating around. Do not invent new ones yet. Put each on its own row with a plain name.
  2. For every idea, choose one decision option, pick a reason code, name an owner and set a review date. Leave blanks visible rather than guessing.
  3. At the review date, keep, change or close each decision. Money, legal exposure or a customer promise needs a named human the same day, not a later revisit.
What you will need before you start
  • A list of AI ideas people have suggested, even if rough or unfinished
  • Someone who can decide what the organisation will and will not spend time on
  • A shared place for the register that the team can find again

The template

Fill in the blanks for your business. This is what you get when you download or copy it.

Register header

Organisation or team:

Register owner:

Last reviewed:

Where this register lives:

Decision options

Give each idea exactly one option.

  • Build: we will design and run something ourselves
  • Assist: a person stays in charge; AI may draft or sort within clear limits
  • Keep human-led: people keep doing this; no AI build for now
  • Defer: worth another look later; not worth attention now
  • Reject: we will not pursue this; record why so it does not keep returning

Reason codes

Pick the code that best matches the decision. Change it at review if needed.

  • No clear bottleneck: the idea does not fix a real delay or repeated friction
  • Founder must decide: the call needs judgment only the founder or owner can give
  • Data not ready: the records, access or definitions are missing or unreliable
  • Legal or privacy risk: personal data, regulated work or unclear permission
  • Already covered: an existing tool or process already does enough of this job
  • Attention cost too high: the idea would cost more focus than it would return
  • Customer promise at stake: the idea touches what customers are told or owed
  • Money or commitment: fees, contracts, refunds or spend need a person

Row fields

Record one row per idea.

  • Idea name (plain language)
  • Decision option (build, assist, keep human-led, defer or reject)
  • Reason code
  • Named owner
  • Review or revisit date
  • Notes (optional; keep short)

Stop rules

  • Any idea that touches money, legal exposure, personal data or a promise to a customer needs a named human owner before anyone spends time or budget on it.
  • Do not treat “assist” as permission to send, spend or commit without that person.
  • A defer without a review date is unfinished; set the date or reject the idea.
See an example

A made-up example, so you can see what a filled-in version looks like.

This is an illustrative scenario, not a client case study or a measured result. Do not reuse its details as facts about your work.

A sample eight-person early-stage SaaS startup in Bengaluru sells a B2B product. The founders have a long list of AI ideas from the team and from investors. Nobody has yet said which ones they will build, which ones a person should keep, and which ones to leave alone.

Sample inputs

Demonstration inputs only: five ideas on a whiteboard. (1) Auto-draft replies to inbound product questions. (2) Score every trial signup for sales priority. (3) Generate weekly investor updates from the tools the team already uses. (4) Auto-approve refunds under a set amount. (5) Summarise support tickets for the product meeting. No usage numbers beyond these five ideas.

Example output

Row 1: auto-draft product replies

[Fact within this demonstration] The team already answers the same product questions by hand several times a week. Decision: Assist. Reason code: Already covered for the answers that are written down; Founder must decide for anything new. Owner: [Name the head of customer success]. Review date: [Four weeks]. [Inference] Drafts may help if they stay inside an approved answer set. That set has not been written yet.

Row 2: score trial signups

[Fact within this demonstration] Sales still opens every trial by hand and has not named what “priority” means. Decision: Defer. Reason code: No clear bottleneck; Data not ready. Owner: [Name the founder who owns sales]. Review date: [Next quarter planning].

Row 3: weekly investor updates

Decision: Keep human-led. Reason code: Founder must decide; Attention cost too high. Owner: [Name the CEO]. Review date: [After the next fundraise conversation].

Row 4: auto-approve refunds

[Fact within this demonstration] Refunds involve money and a customer promise. Decision: Reject. Reason code: Money or commitment; Customer promise at stake. Owner: [Name the operations lead]. [Recommendation] Keep refunds with a named person. Do not build auto-approval. This recommendation is not a substitute for that person’s policy.

Row 5: summarise support tickets

Decision: Assist. Reason code: No stronger claim than “help prepare the meeting pack”. Owner: [Name the product lead]. Review date: [Two sprints]. [Recommendation] Allow a draft summary for the meeting only. The product lead still chooses what goes on the agenda.

How to tell it is done well

Every idea has one decision option, a reason code, a named owner and a review date (or a clear reject); money and customer-promise ideas stay with a person; blanks are visible rather than filled with guesses.

Where a person should decide

The register records choices; it does not prove an idea would work, save money or be safe to run. Reason codes are labels for discussion, not a scoring system. Keep consequential actions with the named human owner.

The register records choices; it does not prove an idea would work, save money or be safe to run. Reason codes are labels for discussion, not a scoring system.

Edit your own copy on this site
About this version

New in Kosh at version 1.1. Provider-neutral Markdown instructions; no installation or platform compatibility is implied. Runtime behaviour has not been verified across AI providers. Reuse terms have not yet been published. Background reading: An AI Audit Should Produce a Non-Build List. Choosing what not to automate, before any build, is part of Kramaniti’s Foundation Strategy audit.

How we write Kosh templates