Every small sales team eventually buys a method, and the method arrives as a vocabulary. Stages are renamed: discovery becomes qualification, and qualification becomes a score. Fields multiply. Somebody writes a document defining what “engaged” means and nobody reads it twice, because the people who would read it are the people doing the work, and the work is answering the two enquiries that came in this morning.
Hygiene is the opposite of that, and it is much smaller. It is the discipline of keeping a handful of fields true — who owns the record, when it was last touched, what happens next and when, what stage it is really at, what it is worth, and where the document is — and deleting everything else. It is not a methodology, it does not need a framework, and it does not depend on a consultant’s definition of anything. It depends on six fields having a named owner and a date, and on one person spending twenty minutes a week on the records that fail.
This piece sets out those six fields, the four stages a document can actually prove, the weekly pass that keeps them true, a worked example of a sixty-two-record export whose arithmetic adds up, what hygiene cannot do, and the decision that starts it — which is as much about what to delete as what to fill in.
What hygiene is, and what it is not
Hygiene is not a way of selling. It says nothing about how to qualify, how to price, how to sequence a conversation or what the stages ought to be called. Those are commercial judgements and every team makes them differently. Hygiene is the property that makes whatever judgement was made legible afterwards: the record says what is known, who knew it, when, and what happens next.
That distinction matters because the two get conflated and the conflation is expensive. A team that adopts a method before it has hygiene spends its energy on definitions and none on the twenty minutes a week that turns a CRM from a shared diary into a record. Six months later the pipeline is a set of numbers nobody believes, and the conclusion drawn is that the CRM does not work — when what failed was the maintenance, not the instrument.
There is a second thing hygiene is not: completeness. A record with six fields filled in, four of them wrong, is worse than a record with two fields filled in and four empty. An empty field is an honest statement that something is not known, and somebody can act on it. A field filled with a plausible date that nobody checked is a claim, and claims get relied on. This is why the pass in this piece is aimed at exceptions rather than at filling blanks: the goal is that every filled field is true and every empty one is known to be empty.
The six fields
Table 1 is the whole of it. Six fields, what each holds, who owns it, and what breaks when it is empty. The fourth column is not a list of inconveniences; each one is the specific failure that makes the record unusable for its only purpose, which is to tell somebody what to do next.
Table 1. The six fields that make a sales record workable, with their owners and the failure each one prevents. Source: the record the sales role drafts against — a brief, a thread, a price list and a terms sheet — reduced to the fields a small team can maintain.
| Field | What it holds | Owner | What breaks when it is empty |
|---|---|---|---|
| Owner | One named person, not a team or a queue | Sales lead | Nobody works the record; it stays open and inflates the pipeline until somebody deletes it |
| Next action | One action, in the imperative, with a date | Account owner | The record cannot be picked up by anybody, including the person who last touched it |
| Last contact | The date and the document: proposal version, email, call note | Account owner | The sequence restarts from the beginning, or stops without anybody deciding it should |
| Stage | One of four, each defined by a document that exists | Sales lead | The forecast becomes a feeling with a number attached, and the number is defended at the monthly review |
| Value | The figure, and the document it comes from | Sales lead | The pipeline total cannot be reconciled to anything, so it is ignored and then distrusted |
| Record link | The proposal, the order or the thread the whole entry refers to | Account owner | Every claim in the record is unverifiable, and the CRM becomes a summary of a document nobody can find |
Three of the six have an owner who is a person, and three have an owner who is a role. That asymmetry is deliberate. The account owner is the only person who can say what happens next on a record, and the sales lead is the only person who can say what the stages mean — because a stage definition that any individual can redefine is not a definition. Where a small team assigns stage definitions to account owners, it gets as many definitions as there are people, and the pipeline review becomes an argument about vocabulary.
The link field is the one that gets dropped first and matters most. A CRM entry that says “proposal sent” is a claim about the world; an entry that says “proposal v3, 6 October, sent to the named approver, link to the PDF” is evidence. The difference costs one paste and it is the difference between a record that can be audited and one that can only be believed.
A stage is a document
Four stages are enough for a small team, and the test of each is the same: what document must exist for this record to be at that stage? Table 2 gives the four with their evidence. There is no fifth stage for “interested”, because interest is not a document, and no stage called “negotiation”, because what happens after a decision is another record rather than a stage of this one.
Table 2. Four stages, each defined by the document that must exist before the record can be at it. The evidence column is the test; a record claiming the stage without the document is at the previous stage.
| Stage | The document that must exist | What the record must show |
|---|---|---|
| Qualified | A brief, a request for proposal, or a reply that names a requirement | The requirement in the buyer’s words, and the date it arrived |
| Proposal | The proposal document, with its version and its date | The requirements answered, the gaps marked, and the validity date |
| Decision pending | The decision requested: a date and a named person who can give it | The date requested, and the route by which the answer will come |
| Closed | A written decision: accepted, or declined, with the date | Which it was, the date, and the reason in one sentence |
The third stage does the most work in a small team, because it is the one that separates a live opportunity from a document somebody is sitting on. A record at “decision pending” has a date and a person; a record whose proposal went out three weeks ago and whose decision date has passed is not at decision pending, it is overdue, and the weekly pass in the next section is built to surface exactly that.
The fourth stage is the one small teams avoid, because a declined record feels like a failure to keep. It is the opposite. A closed record with a reason is the only thing that makes next year’s targeting possible, and a pipeline that contains no declines is a pipeline in which nobody has asked anybody for a decision.
The weekly pass
The pass is twenty minutes on a Monday, and it has three steps in a fixed order.
The first is a list. One call reads the export and returns only the exceptions: records with no owner, no next action, no next-action date, no contact date, a next-action date in the past, a stage with no document, or a value with no source. The list is short by design; a pass that returns everything is a report, and reports are read once.
The second is answers. A person — the account owner, or the sales lead where the owner is absent — answers each exception in a sentence. This is the only step in the whole discipline that cannot be delegated to a document, and it is where the twenty minutes go. Two calls a week: one to build the list, one to record the answers.
The third is a check that the answers landed. Not a re-read of the whole export; a count. Sixty-two records in, the same number out, with the exception list shorter than it was on Monday morning. A pass that does not reduce the exception list is a pass that is being run as a ritual.
The cadence matters less than the ownership. Weekly is chosen because a fortnight is long enough for a next-action date to pass unnoticed twice, and daily is frequent enough that the pass becomes a way of avoiding the work it is meant to protect. The pass is also the cheapest place in the whole sell side to catch the failure that matters most — a decision date that passed while the record still says the deal is live — because the exception list finds it without anybody having to remember to look.
Worked example: sixty-two records, thirty-one of them workable
The export is constructed for this piece: a small team’s pipeline as it stood on a Monday morning, sixty-two records, one owner each on paper and rather fewer in fact. Table 3 sorts every record into exactly one category, so that the categories add to sixty-two and nothing is counted twice.
Table 3. A sixty-two-record export sorted into mutually exclusive categories, with the share of the total and the items each category puts in front of a person. Constructed example.
| Category | Records | Share | Items for a person |
|---|---|---|---|
| Clean: owner, next action with a date, contact date, stage with a document, value with a source | 31 | 50.0% | 0 |
| No next action, or a next action with no date | 14 | 22.6% | 14 |
| No named owner | 9 | 14.5% | 9 |
| Duplicate of another record: two pairs, merging to two records | 4 | 6.5% | 2 merge decisions |
| Stage not supported by a document | 3 | 4.8% | 3 |
| No contact date at all | 1 | 1.6% | 1 |
| Total | 62 | 100.0% | 29 |
The arithmetic is the point of sorting them this way. 31 + 14 + 9 + 4 + 3 + 1 = 62, and the four duplicates are two pairs of two, so merging them leaves 60 distinct records — sixty-two in, two removed, sixty out. Thirty-one records can be worked this morning without anybody being asked anything. Twenty-seven cannot, because each is missing a fact that only a person holds: 14 + 9 + 3 + 1 = 27, which is 43.5 per cent of the sixty-two. Add the two merge decisions and twenty-nine items need a person.
Twenty-nine items at a minute each is twenty-nine minutes — an assumption, stated so it can be argued with, and the only place in this piece where a duration appears. That is one Monday. The pass after it is shorter, because a pass that has been run is a pass with fewer exceptions, and the failure mode of a team that starts hygiene is not the first pass but the fourth, when the list is short and the meeting gets cancelled.
The cost arithmetic is small enough to be worth stating precisely, because the argument for hygiene is never about the money. Two calls a week at the measured Base rate of $0.00700 — one to list the exceptions, one to record the answers — are $0.01400 a week, $0.05600 a month across four weeks, and 96 calls and $0.67200 a year. A monthly call to rebuild the duplicate list is twelve more calls, $0.08400, taking the year to 108 calls and $0.75600.
Set beside the work the pass protects, that is instructive. One proposal drafted is six calls, $0.04200. The four-week pass costs $0.05600, so the whole month of hygiene is cheaper than two proposals — and a record whose decision date passed without being noticed has cost more than that in the proposal it is sitting on and the account it is losing attention from. The figure is not a business case; it is a reminder that the constraint was never the price of the calls, and is always the twenty minutes.
Where a second reader is worth pricing, it is at the monthly duplicate pass, because deduplication is the one step where two models reading the same export will disagree in a way that is itself informative. The same monthly list read on DeepSeek at $0.00700 and on Qwen flash at its measured $0.00875 is $0.01575 a month, $0.18900 a year, for two lists whose differences can be read as a check on the first.
What hygiene cannot do
The first limit is that hygiene cannot supply a fact nobody has. Of the twenty-nine items in the example, most need somebody to say what happened: whether the buyer replied, whether the decision date is still the decision date, whether the duplicate is genuinely a duplicate. The pass finds them; a person answers them; nothing in the software knows.
The second is that sorted records are not a pipeline. Sixty-two records in six clean categories is an accurate description of what is known, and it says nothing about what will be sold. A team that treats a clean CRM as a forecast has confused the instrument with the judgement, and the judgement is somebody’s, made weekly, about specific records.
The third is that every field has a maintenance cost that is invisible until the fourth week. Six fields across sixty-two records is 372 values to keep true, and each one that is added costs a minute a record a week. That arithmetic is why the field set here is six and not twenty: not because twenty would be less useful, but because twenty cannot be maintained by a team that also has to sell.
The fourth is that the definitions decay. A stage definition written in January describes evidence that January understood; by June the business has changed and the definition has not. The sales lead owns the definitions for this reason, and the review of them belongs in the same twenty minutes as the pass — one sentence a quarter, not a project.
The fifth is that the record is not the decision. The CRM says a proposal was sent and a decision is due; the decision is in the buyer’s building, and the evidence of it is a document. Where a record and a document disagree, the document is true and the record is wrong, and any team that has ever marked a deal won on the strength of a friendly email knows exactly how expensive that inversion is.
The sixth is that none of this has been measured. This piece quotes no time saved, no accuracy improvement, no effect on revenue and no benchmark from any other team, because none has been measured by this publication. What it describes is a field set and a pass, both of which can be checked against a real export in an afternoon — which is the only validation it claims.
The decision
Choose the six fields this week and name an owner for each, and choose them by subtraction: list every field the CRM currently has, ask who has read each one in the last quarter, and delete the rest. A field nobody reads is a field somebody maintains for no reason, and it is the reason hygiene projects fail — the surface to keep true grows until nobody keeps any of it true.
Then define the four stages by document, once, and put the definition where the team will see it: qualified means a brief, proposal means a proposal, decision pending means a date and a named person, closed means a written answer. A stage that cannot be checked against a document is a feeling, and feelings are what the pipeline review argues about.
And run the pass on Monday, twenty minutes, exceptions only, with the count checked at the end. The pass is the entire control; everything else in this piece is the shape of what it maintains. A team that runs it for a month will have a record it can read; a team that adopts a method instead will have a vocabulary and the same sixty-two records.
Where this goes
- The pillar: x402.review/2026/10/31/commercial-operations/ — one record, two readers, and the approvals between them
- The role that works the record: studio.x402.press/roles/sales — the proposal, the follow-up thread and the mailbox it sends from
- Why a dated entry beats a described one: approval limits and segregation of duties — the same argument about signatures, evidence and dates
- The service it buys: x402.press/services/deepseek/ — the canonical price, seven chains
- The review: x402.review/2026/10/31/deepseek-review/ — the measured handshake and what it does not promise
Method note
The price was read from the live 402 challenge on Base on 31 October 2026, a Saturday and therefore outside DeepSeek’s weekday peak windows: 7000 atomic units under exact, which is $0.00700, and 9550 under upto at the max_tokens tested. Qwen flash’s $0.00875 was read from its own challenge the same day. Call counts are planning assumptions, stated where they are used: two calls a week for the pass, one a month for the duplicate list.
The sixty-two records, the categories, the duplicates and the twenty-nine items are constructed for this piece to show the arithmetic of a sort that adds to the total. They describe no real team, export or pipeline. The one duration quoted — a minute an item — is labelled as an assumption. No time saved, revenue effect, accuracy improvement or benchmark from another organisation appears anywhere here, because none has been measured.
x402.review is written and edited by N.P. Vincent. The publication is connected to x402.press, which sells the services reviewed here; that interest is disclosed on every piece that touches a service, and it is stated here rather than left to inference.
Filed under Jobs · Tags: crm, data-hygiene, small-teams, process
