Turn a raw keyword export into a cannibalization-proof cluster map

You are an SEO information architect deciding how many pages a keyword list actually justifies — not how many keywords it contains.

SITE CONTEXT: we sell CRM software aimed at small teams under 20 people, self-serve signup with no sales calls
RAW KEYWORD LIST (with monthly search volume if available):
best crm for small business (2400)
crm software comparison (1900)
free crm for startups (1600)
crm pricing (880)
how to choose a crm (720)
crm implementation checklist (390)
EXISTING PAGES ALREADY LIVE, IF ANY: /pricing — current pricing page; /blog/crm-vs-spreadsheets — comparison post

TASK

1. GROUP BY INTENT, NOT WORDS. Cluster these keywords into groups a single page could realistically satisfy without competing against another page on this same site. Two keywords sharing several words but serving different intents — "crm pricing" and "crm software comparison" is the canonical example — must NOT be forced into one cluster unless you can name the specific reason one page genuinely covers both.
2. NAME EACH CLUSTER by the page title it implies, outcome-first, not the seed keyword restated.
3. FOR EACH CLUSTER, state the dominant intent (informational / commercial-investigation / transactional) and the single keyword that becomes the page's primary target. Every other keyword in that cluster becomes a secondary target the page earns through topical depth — never a second H1 competing for the same click.
4. FLAG CANNIBALIZATION RISK explicitly: any two keywords across the whole list, not just within one cluster, that look like they'd want the same page. For each pair, recommend which one becomes primary and which folds in as supporting content, rather than leaving both to become competing pages later.
5. FLAG WHAT YOU CANNOT CONFIDENTLY CLUSTER — ambiguous keywords whose intent genuinely depends on the searcher's stage or on business context you don't have — and state exactly what additional information would resolve it. Do not force a confident-sounding cluster onto an ambiguous keyword just to avoid an "unclear" answer.
6. IDENTIFY THE PILLAR-CLUSTER HIERARCHY: if any clusters are naturally subtopics feeding a broader pillar page, name the pillar and which clusters should link up to it rather than sit as unrelated siblings.
7. If /pricing — current pricing page; /blog/crm-vs-spreadsheets — comparison post is provided, check whether any new cluster would compete with a page that already exists rather than filling a genuine gap, and say so before recommending a new page be built.

OUTPUT
A table: Cluster name | Primary keyword | Secondary keywords | Intent | Suggested page type. Follow it with the cannibalization-risk list, the unclustered/ambiguous list, and the pillar hierarchy, each as its own labeled section.