What data should I collect to improve my ICP over time?
Collect account-linked evidence of the buyer's situation, observed trigger, current workaround, exact objection and agreed next step. After purchase, add the first confirmed outcome and delivery burden. Preserve the source, date, owner and uncertainty for each observation. Automate identifiers and events, while people confirm meaning, commitments and customer value.
What decision should the evidence record support?
An ICP evidence record should help a post-seed team understand which buyer situations lead to a suitable purchase and a useful customer outcome. Collect a field only when someone can explain the decision it supports.
Company attributes alone are insufficient for that purpose. Industry and size can help find accounts, but they do not explain why a project started, what the buyer tried or what happened after implementation. Conversely, a transcript archive may contain rich detail that nobody can compare across accounts.
Start with a lean account-linked record and add evidence over time. This page defines the evidence supply. The actual decision to change a targeting criterion belongs in refining an ICP from sales evidence.
What is the minimum useful record?
Keep identity, source, buyer situation, commitment and outcome distinguishable. The following field groups are a starting design, not a validated universal schema or a demand that sales fills every field immediately.
| Field group | What to capture | Capture moment and owner |
|---|---|---|
| Account and opportunity | Stable IDs and confirmed relationship | CRM owner at creation or matching |
| Evidence source | Original note, reply or recording reference and date | Intake system, checked by the contributor |
| Buyer situation | Relevant workflow and current alternative | Founder or seller after discovery |
| Observed trigger | Recent event that prompted action | Seller when the buyer describes it |
| Objection | Confirmed wording, plus a separate interpretation | Seller when the objection occurs |
| Next step | Action, participants, owner, date and agreement status | Seller with buyer confirmation |
| Fit and unknowns | Evidence against the current criterion | Seller or designated reviewer |
| First outcome | Defined result, observation date and conditions | Delivery owner with customer input |
| Delivery burden | Implementation work, exceptions and unusual help | Person responsible for delivery |
| Evidence control | Status, reviewer, access and review or removal rule | Evidence owner when added and reviewed |
Do not collapse all of this into one account score. The score may be useful for routing later, but the underlying observations must remain available. A missing implementation detail should remain missing, rather than become a negative fit value by default.
How do you connect accounts, people and evidence?
Use stable identifiers to connect an observation to an account and opportunity. Names, email domains and free-text company labels can help matching, but should not silently become the sole identity rule.
One person may participate in several projects or belong to several organizations. One account may have several opportunities with different outcomes. Preserve those relationships so a stalled pilot does not automatically describe every future opportunity at that account.
Segment’s Group specification explicitly distinguishes user identifiers from group identifiers and allows a user to belong to multiple groups. It also warns that destination support differs. If you use that route, verify what each destination actually receives; the account relationship is not guaranteed just because an event was tracked.
Productboard’s note model offers another existing example: notes carry source metadata and ownership and can relate to customers. You can reuse the principle in the workspace you already have. Buying Productboard or an analytics platform is not a prerequisite for a small evidence record.
Which facts are commonly mixed together?
Separate acquisition source, buyer trigger, seller intention and buyer commitment. They answer different questions and should not be substituted for one another in reporting.
| Observation | What it can tell you | What it cannot establish alone |
|---|---|---|
| Recorded traffic source | How an associated interaction was categorized | Why the buyer started a project |
| Buyer-described trigger | What changed in the buyer’s situation | That the product will solve the problem |
| Seller’s next action | What your team intends to do | That the buyer agreed to participate |
| Accepted next step | A specific commitment to continue | That a purchase or outcome will follow |
| Closed-won stage | An opportunity was recorded as won | That implementation or customer value occurred |
| Product event | A specified action occurred in the product | That the customer’s intended benefit was achieved |
HubSpot’s default deal properties illustrate these distinctions. Original traffic source can derive from associated contact or company activity. Its Next step field describes what the user will do to improve the deal’s likelihood. Neither definition makes that field a buyer-confirmed commitment.
Write your own field definitions before automating them. If a dashboard labels all populated next steps as buyer commitments, correct the definition and capture path. Do not compensate by asking AI to make the field sound more specific.
How should buyer words and interpretations be stored?
Preserve the source wording separately from the category or conclusion you assign to it. A standardized objection label is an interpretation, even when it is a useful one.
Use quotation marks only for wording checked against the original source. Label a seller’s reconstruction as a paraphrase. Link a short excerpt to the surrounding passage so another reviewer can inspect context. Avoid keeping unnecessary personal detail merely because it appeared in the conversation.
Give interpretations a reviewer and status such as proposed, confirmed, disputed or unknown. Let a colleague disagree without editing away the original observation. When the buyer corrects a fact, make that correction visible to people using the earlier summary.
Technical change history helps but serves a different purpose. HubSpot property history shows changed values, dates and sources. That can explain how a field changed. It does not establish that the field is factually correct or preserve the full conversation behind it.
What should you add after the sale?
Add the first customer outcome and the effort required to reach it. Otherwise the record favors accounts that are easy to close even when the product is difficult for them to use successfully.
Define the outcome in the customer’s workflow. Record the relevant product event, the customer’s confirmation and any conditions separately. Setup completion may be an intermediate milestone. It should not automatically become evidence that the promised benefit occurred.
Capture delivery burden in terms the team can compare: unusual migration work, manual service, repeated support, founder intervention or a missing capability. Include who supplied the effort and whether it is repeatable. An outcome reached through exceptional help is useful evidence, provided the help is visible.
Do not invent a universal acceptable burden. The product, offer and delivery model determine what is sustainable. Keep customer feedback and operational observations together so the founder can judge whether a second similar customer would be well served.
Which parts can be automated safely?
Automate identifiers, timestamps and observed system events where the source supports them. Have a person confirm the meaning of buyer statements, agreed commitments and claimed customer value.
- Map each field to an authoritative source or a named contributor.
- Let integrations attach stable IDs, event dates and original references.
- Use AI to propose summaries and labels with links to the source passages.
- Send ambiguous matches and unsupported statements to review.
- Write confirmed interpretations only after the responsible person checks them.
- Track corrections and notify owners of records that used the earlier interpretation.
Make the write path visible. A user-facing required field does not prove every import or integration supplies it correctly. Test normal entry, automated creation, missing sources, repeated events and corrected account matches.
Choose the minimum capture work before expanding the stack. The operating sequence is described in what to automate before GTM headcount.
How do you control access, retention and removal?
Decide why each piece of evidence is retained, who may see it and what happens when that purpose ends. Apply the policy to recordings, extracted quotes, summaries and exports rather than only the visible CRM row.
The EDPB’s data protection basics explain purpose limitation, necessary and proportionate collection, accuracy and retention linked to purpose in the EU framework. Audio recordings can contain personal data. These principles do not supply one retention period for every startup or establish the lawful basis for your particular use.
Set a review or removal rule when collecting the material. Keep access limited to the people who need it. If a source is corrected, restricted or removed, identify the dependent records and decide what must also change. Preserve necessary decision history without treating that as a reason to keep every raw recording indefinitely.
When evidence feeds public or sales material, track those uses through founder insights into linked GTM assets.
How do you know the record is useful?
Judge evidence quality by whether the team can answer a real decision question with traceable observations. High field completion alone can reward guesses and boilerplate.
Record the review date and use the same definitions and account or record scope in successive reviews. The following is a proposed review record, not a universal quality benchmark.
| Check | Definition for the review | What to record next |
|---|---|---|
| Unmatched account | An observation has no confirmed account or opportunity relationship | Source reference, unresolved match and matching owner |
| Missing source link | An observation has no retrievable original reference or its linked passage cannot be located | Affected record, missing reference and contributor responsible for repair |
| Disputed interpretation | A conclusion has unresolved disagreement about the source’s meaning | Original observation, competing interpretation and reviewer |
| Missing post-sale outcome | A purchased account reaches its agreed outcome review point without a recorded result and customer confirmation | Outcome definition, due review and delivery owner; keep not-yet-observed outcomes separate |
| Capture effort | Work required to capture, check and repair the covered records | Capture task, person doing it and recurring rework |
Ask a colleague to retrieve the evidence behind an objection or a fit conclusion. If they cannot, improve the capture route before adding more fields. Compare missing records within the stated scope; a full field is not evidence that its contents are correct.
Use what to measure in early GTM tests to connect the record to a specific experiment. Keep capture requirements light enough that the founder, sales and delivery actually maintain them.
Making the evidence supply work in practice
Piet Baudoin of Poldermarketing works remotely in Dutch and English with post-seed startups moving from a first customer to a second and then a repeatable go-to-market process for customers who are genuinely happy with the product. He can set up the CRM and read Search Console queries alongside positioning and visibility in Google and AI answers.
He builds and runs AI automations with care: lead follow-up, enrichment and qualification, reporting, content distribution and tool integrations. The founder and team keep responsibility for what the evidence means. Explore positioning and messaging or request the free growth scan.
Questions people ask
Should every field be mandatory on the first call?
No. Capture information when the relevant event occurs and someone can verify it. A first conversation cannot supply a customer outcome or complete delivery record. Use unknown and not yet observed deliberately. Requiring speculative answers can produce a complete-looking CRM that is less useful than a smaller set of reliable observations.
Is CRM attribution the same as a buying trigger?
No. Attribution describes a recorded acquisition source or interaction. A buying trigger describes what changed in the buyer's situation and prompted action. Keep both when useful, with separate definitions and sources. Do not infer that a campaign click caused the project or that a founder introduction explains the underlying need.
What is the right first-value event?
Define it for the product and buyer outcome. Completing setup or logging in may be necessary without demonstrating value. Record the product event and the customer's confirmation separately, along with the date and conditions. Do not copy another company's activation milestone and assume it proves that your customer benefited.
How long should we retain call recordings?
Choose a documented period based on the purpose, applicable obligations and access needs, rather than copying a universal number. Include recordings, quotations, summaries and exports in the policy. Review whether the original is still needed after a checked observation exists, and make removal or correction traceable across linked records.