A tier column typed from memory decides nothing. Stored as an object with a negative gate, the buyer becomes a score every later stage can read.
A tier column nobody trusts. Someone types A, B or C beside each company, from memory, on a Tuesday. At a forty-person firm nobody can say what B means, so nothing downstream dares read it.
By hand today
“populated by you and your users”
HubSpot, on its default company properties
That is how the standard CRM describes its Ideal Customer Profile Tier field. It is a label you fill in. The tool holds it and does nothing with it. Users have asked to change the three fixed values it offers, which tells you how often the three do not match the sentence a company actually sells by.
So the tier gets typed from memory. One person means “big enough to pay” by tier A, another means “we have a contact there”. The column fills up and quietly becomes a record of who was in a good mood. Nothing later in the engine reads it, because nobody trusts it enough to let it decide anything.
The sentence from chapter 1 is precise. The tier column is not. This stage is the translation between them.
What it costs you each week
Ten hours reading four hundred companies and typing a judgement beside each one, by hand, once. Then again next quarter, because nothing recorded why any of them scored the way it did.
Source: modelled. 400 companies at 90 seconds each, one person judging by hand
No vendor publishes what the hand version costs, so that figure is modelled, and the assumption is on the record: four hundred companies, ninety seconds each to open the record, form a view and type it. That is ten hours.
The ten hours are not the real damage. The damage is that the reasons were never written down, so the next person cannot check the judgement, and the next run starts from nothing. Scoring without stored reasons is work you buy repeatedly.
The build
Open Codex and store the ICP as an object. One file holds the titles that count, the size band, the weights, and the gate that rules a company out. Every company then gets a score with its reasons, or the words not scored. Never a bare number.
Work in the folder holding buyer.md from the previous chapter and an export of companies, however rough. Ask for the object and the scorer together.
Read buyer.md. Write icp.json holding: the job titles that count as the
buyer, the headcount band, any ownership condition, and a list of
negative gates written as conditions that rule a company out outright.
Then write score.py: for each row in companies.csv, apply the negative
gates first, then score what is left against the bands and weights, and
write score, band and a reasons list naming the fact behind each point.
Where a required fact is missing, write not scored, never zero. Report
four counts: gated out, scored, not scored, and the total read.
What comes back is a file you can read in a minute and a script that turns a list into scored rows with reasons attached. Read the gated-out rows first. If a company you want is sitting in that pile, the gate is wrong, and one gate is easier to fix than a thousand scores.
The negative gate is the part most people miss. ArkOne stores its own buyer as an ICP object in the platform rather than as a column: the titles that count, a headcount band of 51 to 1,000 people, privately held, and one gate written as !has-ai-capability. The platform documentation calls that gate “a gate, not a weight”, which is the whole ruling in four words. A company that fails it is out, however well it scores everywhere else. The object also carries a spec field holding the search queries in the shape the data vendor expects, plus the bands, the weights and the thresholds, so the same definition drives search and scoring. It is written down in docs/crm-module.md.
You build your own. The path is the pattern to copy: one stored object, one negative gate, and a score that arrives with its reasons.
What it feeds
The two channels that matter. Once companies carry a score and a band, you can ask which channel actually reaches the band you want. The next chapter picks two and closes the rest, a question that is unanswerable while the list is a tier column.
The number that proves this stage worked is the count of scored companies with reasons, shown with a total beside it. A count with no total hides everything it did not read. On ArkOne’s own run the figure was 632 qualified companies carrying a domain, recorded in the campaign learnings file with the date it was counted.
What stays with a person
The borderline title. A managing director in one country is the buyer. In another, the same words mean a middle manager.
The gate and the weights are mechanical. The edges are not. Titles do not mean the same thing in every market, and a founder who calls themselves head of growth still signs the contract. No scorer can settle that, because it depends on facts about the market that live in a person.
So a person rules on the edge case once. The ruling goes into the object, dated, in the same file the scorer reads. It never has to be argued twice, and when it changes, it changes in one place.
The tools you already pay for
Nothing new to buy.
CRM already has somewhere to put this. The change is that it stops holding a label and starts holding a definition every later stage reads.
Export is the list you have today. It does not need cleaning first, because the scorer reports what it could not read.
Codex writes the object and the scorer in the same session, so the definition and the code that applies it never drift apart.
The buyer is now a stored object with a gate, and every company carries a score with its reasons. Then the channel choice is arithmetic.
Ask: If someone asked why that company is tier B, could your CRM answer?
This is chapter 2 of twelve, after the one sentence that decides who you sell to; chapter 3 picks the channels. The book, Building a real GTM engine with Claude Code and Codex, end to end, runs the whole engine in order, one chapter per stage. A free starter edition for firms under fifty people is coming through the 100k programme.