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

Version 1.1 · Kramaniti Kosh

## Intended outcome

A short register of AI ideas, each with a clear decision, a reason, a named owner and a date to look again.

## Before you begin

- 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

## How to use

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.

## Working template

## 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.

## Demonstration

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.

## Quality check

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.

## Limits and human review

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.

## Edition notes

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](/insights/an-ai-audit-should-produce-a-non-build-list/). Choosing what not to automate, before any build, is part of Kramaniti’s [Foundation Strategy](/#services) audit.