US & Global
For fifteen years, the content strategy of a parts retailer, a distributor or a component manufacturer amounted to writing in order to rank a category page: "shocks for pickup trucks", "ceramic brake pads", "performance air filters". Everyone competed on product terms against marketplaces with ad budgets no mid-sized player could match.
That battlefield is already lost for most of them, and it is also changing shape. Two things happened at the same time.
The first is that search stopped being a directory of links and became an answer engine. Rich results, featured snippets and generative summaries resolve the query before the user ever clicks. If your content is not the source feeding that answer, you are invisible even when you rank on the first page.
The second is that a growing share of diagnostic queries no longer starts in a search box. It starts in a language model. A mechanic with a phone propped against the hood describes a symptom to a conversational assistant and gets back a probable diagnosis, a list of causes and, if the model has something to draw on, a part number. That model is not reading your catalog. It is reading the body of technical content it encountered during training or during a live search.
The strategic question is no longer "how do I rank my product page". It is "how do I become the source the machine cites when someone describes a fault".
The most common mistake is competing for the wrong query. Nobody with a real problem searches for "buy oxygen sensor". They search for "why does my engine hesitate when cold", "what does code P0420 mean" or "whistling noise under acceleration on a turbo engine". Purchase intent exists, but it sits buried underneath a layer of diagnostic intent.
Whoever resolves the diagnosis gets the sale. This has always been true in the physical shop: the customer buys the part from whoever explained what was wrong with the car. The strategy consists of moving that dynamic into the digital plane and running it at scale.
The asset being built is a technical repository: a body of structured content that answers diagnostic queries with verifiable precision and that, at the exact point where the reader confirms their suspicion, shows them the part with its number, its fitment and its price.
Worth saying before the word automation comes up, because it arrives contaminated: this is not a content farm with a language model writing by the yard.
The difference is not whether a machine wrote the text. It is where the knowledge comes from. In a content farm the model writes from its own weights: it recites what statistically sounds like automotive writing, invents plausible part numbers and produces prose that is grammatical and technically useless. In a serious system the model supplies none of the knowledge. It supplies composition and assembly. The knowledge comes from your catalogs, your technical bulletins, your return history and the heads of your technical staff.
From that follows the rule that organizes the entire design: no factual claim gets published unless it traces back to a verified record. Part numbers, cross-references, fitment ranges, prices, torque specs, capacities. If the data is not in the source, it does not appear in the article, no matter how willing the model is to offer it.
In auto parts this is not an editorial concern. A hallucinated OEM number ends up as the wrong part installed in someone's car.
No generation engine works on top of a vacuum. Before writing the first line of code, settle where the technical data comes from and how much each source can be trusted:
Those sources get normalized into a single data model: one canonical record per combination of fault, vehicle platform and part, with typed fields and the provenance of every value recorded. That record is the unit of work for the whole system. Everything downstream is a transformation on top of it.
On that base sit the three taxonomies that structure the topic inventory:
The intersection of the three produces the content map. There is no need to invent topics: the catalog and the fitment tables already contain thousands of legitimate combinations.
This is the core of the project, and the right way to think about it is as software, not as an AI-assisted editorial workflow.
What gets built is a codebase in an AI-assisted development environment, Cursor or equivalent, in Python or TypeScript. It lives in a repository, it is version controlled, it has tests and it ships. The coding assistant accelerates building it; it does not replace it.
A reasonable structure:
/sources ingestion adapters, one per data source
/schema the canonical data model and its validations
/rules templates, nomenclature glossary, explicit prohibitions
/golden reference articles written by a human specialist
/pipeline the transformation stages
/checks deterministic validators
/adapters publishing targets
/evals output compared against the golden set
The engine runs as a pipeline of stages, each with an inspectable output:
Ingestion and normalization. Adapters read each source and emit canonical records. No language model is involved here: this is parsing, mapping and type validation. If a catalog carries garbage, it surfaces here rather than thirty steps later.
Prioritization. The system crosses the taxonomies, drops combinations already covered and ranks the rest against defined criteria: estimated query volume, margin on the associated part, inventory availability, failure frequency in your own history. The output is a work queue, not an improvised list of headlines.
Drafting. Here the model enters, and it enters constrained. It receives the canonical record, the structural template, the nomenclature glossary for the target market and the prohibitions. Its job is to compose, not to recall. Hard data is injected as fields; it is never requested from the model.
Deterministic verification. Before any human sees anything, the article goes through checks that require no judgment and fail in binary fashion:
This stage is what makes volume possible. Every check that can be automated is human time freed for the parts that actually need judgment.
Human review. What survives reaches a review queue with the checks already resolved and the exceptions flagged. The reviewer is not fixing commas; they are judging whether the diagnosis is right and whether the article deserves to exist.
Rendering and publishing. The final stage converts the approved article into the target format and ships it.
That last point is worth insisting on, because it tends to inflate into a project phase and it is not one. Publishing is a thin adapter at the end of the pipeline. The target can be a commerce platform's admin interface, a headless CMS, a repository of markdown files feeding a static generator, or some combination. The pipeline does not change. The final adapter does, and it is usually a couple hundred lines of code. Designing the system around one specific platform makes it fragile for no reason.
One practice separates a maintainable system from one that degrades quietly: before generating anything, a human specialist writes ten to twenty reference articles by hand, covering the representative cases including the hard ones.
That set serves three purposes. It is the operational definition of "good": the template and rules are written to reproduce it, not the other way around. It is the regression test: every time a prompt or a rule is touched, or the model is swapped, output is compared against it and you can see what broke. And it is what lets a business change model providers without rebuilding the project.
Without a golden set there is no way to know whether a change improved the system or degraded it. You work on impression, and working on impression is how you end up publishing garbage without noticing.
The repository needs three things from its destination: an owned domain, stable URLs and the ability to update programmatically. Everything else is negotiable.
There is one line worth not crossing: hosting the content on someone else's domain, whether a third-party publishing platform or a blogging service, builds authority for the third party rather than for the business.
Within your own domain, the choice between subfolder and subdomain depends on the scenario. A subfolder, domain.com/guides/, is the sensible starting point for a single-brand business selling online: signals accumulate on one entity and commercial integration is native, because the product card, the session and the cart live in the same place as the article.
A subdomain makes sense when the commerce platform cannot support the structure the project needs without compromising performance, when volume calls for an independent stack with a static generator or headless CMS, when the repository serves several brands within one group, or when IT constraints rule out touching the root. Its cost is that it splits signals across two properties and forces you to solve internal linking and session and cart continuity toward the store separately.
The practical criterion: if content and catalog sell each other within the same session, use a subfolder. If the repository is an editorial product with its own infrastructure and lifecycle, use a subdomain with an explicit plan for linking and handoff to the store.
When a commerce platform's content module is used, rename the path with a term that declares what it holds rather than leaving the generic "blog": guides, diagnostics, technical manual. The name matters less than the consistency and depth of what sits behind it.
The structure is not an aesthetic decision. Each block serves a specific function for a different reader: the search engine, the language model and the person with the broken car.
The title combines symptom, fault code and vehicle platform, because that is how the user phrases the query. The opening paragraph delivers the complete answer in under fifty words: what the code means, what causes the symptom in most cases and which part resolves it.
That initial compression is what a search engine extracts for a featured snippet and what a language model uses as a synthesized answer. If the answer sits in paragraph eight, extraction never happens.
The table organizes information into a matrix of probable cause, characteristic symptom, replacement part and repair difficulty.
Language models process relationships. A table hands them the relationship already built, with no syntactic ambiguity to resolve. It is the format with the highest information density per token and the one most likely to be reproduced in a generative answer.
For the human reader it serves a different purpose: in three seconds they confirm or rule out their suspicion and know which part they need.
The part appears at the point in the text where the reader has just confirmed the diagnosis, not at the end. Placing the offer after two thousand words destroys conversion for someone who already decided in paragraph four.
The card carries the full part description, the compatible year and model range, the brand, the OEM reference number, the price and a direct link to the product page. It is contextual advertising with no media cost, served at the moment of maximum intent.
A sequence of verifiable steps demonstrates practical experience. It is the hardest signal to fake and the one that separates a specialist's content from a generic writer's.
It is also the format models extract verbatim when someone asks how to test for a fault. A well-built numbered list is a prefabricated conversational answer.
HTML is for people; structured markup is for machines. A JSON-LD block explicitly declares that the document is a technical article, which fault code it covers, which product it mentions, with which part number and from which brand.
This removes the interpretive margin. Instead of waiting for the system to infer what the content is about, you hand it the classification already resolved:
html
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "TechArticle",
"headline": "Code [OBD2 code] on [engine platform]: causes and fix",
"description": "Diagnosing and repairing [fault] on [engine platform].",
"about": {
"@type": "Thing",
"name": "OBD2 code [code]"
},
"mentions": [
{
"@type": "Product",
"name": "[Part description]",
"mpn": "[OEM number]",
"brand": { "@type": "Brand", "name": "[brand]" }
}
]
}
</script>
The markup is rendered from the same canonical record fields that feed the article body, never assembled separately. That is the only way to guarantee that what the text says and what the markup declares do not contradict each other.
Automation handles retrieval, assembly, formatting, validation and publishing. Judgment stays on the human side, and it is worth being explicit about where exactly:
Source selection and trust hierarchy. Which catalog wins when two disagree. That is a business decision and it does not get delegated.
Authoring the template, the glossary and the rules. The constraint system is written by someone who knows the market. A nomenclature glossary generated by the same model that will consume it constrains nothing.
The golden set. Written by hand, by a specialist.
Exception review. Anything failing a hard check goes to a person. It does not self-correct.
Batch sampling. With explicit acceptance criteria and a defect rate that, once exceeded, sends the whole batch back.
The decision not to publish. The most important one, and the one no automated system makes well. A topic covered badly, a data point you are not confident in, a discontinued part: those get dropped, and dropping is human work.
There is an asymmetry worth holding onto. Publishing one bad article costs more than not publishing ten good ones, because the damage is not confined to that page: it contaminates how the whole repository is perceived, by readers and by the systems evaluating it.
The reference articles get written by hand, the pipeline gets built and it runs against a small batch. The goal is not volume but calibration: getting the system's output publish-ready without intervention in the large majority of cases.
Publishing happens by hand, whatever the destination, and the content gets checked on the real site: how tables behave in the installed theme, how product cards behave on mobile, how the markup fares in the validator. Rules get corrected against the golden set until the comparison stops surfacing meaningful differences.
This phase is deliberately slow. Every defect not caught here gets multiplied by the scale factor of the next one.
The publishing adapter goes live and volume increases, but every article still passes through review before it ships. Human work speeds up because deterministic checks arrive already resolved, not because review disappears.
This is where the real per-article review cost surfaces, and where the system gets tuned to bring it down. The answer is almost always to tighten the rules or improve the input data, not to review faster.
Once the defect rate settles below the agreed threshold, review moves from exhaustive to sampled, with defined escalation criteria. A second agent gets built specifically for quality control, evaluating technical coherence and nomenclature consistency before a human steps in, acting as a pre-filter rather than as the final approver.
Data integrations get maintained, articles get updated when prices or cross-references change, and the eval suite runs every time the model or the rules are touched. This phase has no end date. It is the cost of keeping a living asset.
The metrics for this strategy are not the metrics of a paid campaign, and they do not mature in the first month.
In the short term you watch indexed content volume, appearances in featured snippets and impressions on diagnostic queries, kept separate from brand and product queries.
In the medium term what matters is citation in generative answers. This is measured by building a fixed set of representative queries and running them periodically against the major conversational assistants, recording whether the domain shows up as a source. It is a manual or semi-automated measurement, but it is the only way to know whether the strategy is working in the channel it was designed for.
Commercially, you measure assisted conversion: the share of sessions that enter through a technical article and end in a transaction, and the repository's contribution to total revenue.
One internal metric is worth tracking from day one: defect rate per batch and human review time per published article. If the first does not fall and the second does not give, the system is not scaling even if volume grows.
The architecture stays the same; what changes is the axis of the content.
A parts retailer organizes the repository around part number and fitment, with the direct sale as the destination.
A repair shop or service chain organizes it around symptom and procedure, with the service appointment as the conversion and explicit geographic segmentation.
A wholesale distributor organizes it around cross-references and availability, aimed at a professional reader buying in volume.
A component manufacturer organizes it around specification and failure mode, in order to install its own nomenclature as the market reference.
Phases one and two resolve within roughly three months, with room to move depending on how fast volume is meant to scale. Inference credit consumption is proportional to that speed and is the system's main variable cost, alongside specialist review hours.
Phase three is a permanent commitment: maintaining the engine, updating data, optimizing quality control and periodically revisiting the approach as search and assistant answer formats change.
What gets built is not a campaign, and it is not an archive of articles either. It is a production system with human judgment designed into it, and a body of verifiable content that is hard to replicate for a competitor without the data, the technical judgment and the infrastructure.
atQuo is a creative partner that operates at the intersection of design, technology, and marketing strategy. Our **Insights and Talks** exist to demystify this intersection, sharing the expert knowledge required to make smarter decisions about the tools and tactics that drive growth. This same expertise fuels our services, where we execute on that strategy to build powerful digital experiences that help brands scale with clarity and confidence.
The decisions behind how we design and build. Animations, components, variables, structure — the reasoning we've written down so we don't have to reinvent it every time.
For fifteen years, the content strategy of a parts retailer, a distributor or a component manufacturer amounted to writing in order to rank a category page: "shocks for pickup trucks", "ceramic brake pads", "performance air filters". Everyone competed on product terms against marketplaces with ad budgets no mid-sized player could match.
That battlefield is already lost for most of them, and it is also changing shape. Two things happened at the same time.
The first is that search stopped being a directory of links and became an answer engine. Rich results, featured snippets and generative summaries resolve the query before the user ever clicks. If your content is not the source feeding that answer, you are invisible even when you rank on the first page.
The second is that a growing share of diagnostic queries no longer starts in a search box. It starts in a language model. A mechanic with a phone propped against the hood describes a symptom to a conversational assistant and gets back a probable diagnosis, a list of causes and, if the model has something to draw on, a part number. That model is not reading your catalog. It is reading the body of technical content it encountered during training or during a live search.
The strategic question is no longer "how do I rank my product page". It is "how do I become the source the machine cites when someone describes a fault".
The most common mistake is competing for the wrong query. Nobody with a real problem searches for "buy oxygen sensor". They search for "why does my engine hesitate when cold", "what does code P0420 mean" or "whistling noise under acceleration on a turbo engine". Purchase intent exists, but it sits buried underneath a layer of diagnostic intent.
Whoever resolves the diagnosis gets the sale. This has always been true in the physical shop: the customer buys the part from whoever explained what was wrong with the car. The strategy consists of moving that dynamic into the digital plane and running it at scale.
The asset being built is a technical repository: a body of structured content that answers diagnostic queries with verifiable precision and that, at the exact point where the reader confirms their suspicion, shows them the part with its number, its fitment and its price.
Worth saying before the word automation comes up, because it arrives contaminated: this is not a content farm with a language model writing by the yard.
The difference is not whether a machine wrote the text. It is where the knowledge comes from. In a content farm the model writes from its own weights: it recites what statistically sounds like automotive writing, invents plausible part numbers and produces prose that is grammatical and technically useless. In a serious system the model supplies none of the knowledge. It supplies composition and assembly. The knowledge comes from your catalogs, your technical bulletins, your return history and the heads of your technical staff.
From that follows the rule that organizes the entire design: no factual claim gets published unless it traces back to a verified record. Part numbers, cross-references, fitment ranges, prices, torque specs, capacities. If the data is not in the source, it does not appear in the article, no matter how willing the model is to offer it.
In auto parts this is not an editorial concern. A hallucinated OEM number ends up as the wrong part installed in someone's car.
No generation engine works on top of a vacuum. Before writing the first line of code, settle where the technical data comes from and how much each source can be trusted:
Those sources get normalized into a single data model: one canonical record per combination of fault, vehicle platform and part, with typed fields and the provenance of every value recorded. That record is the unit of work for the whole system. Everything downstream is a transformation on top of it.
On that base sit the three taxonomies that structure the topic inventory:
The intersection of the three produces the content map. There is no need to invent topics: the catalog and the fitment tables already contain thousands of legitimate combinations.
This is the core of the project, and the right way to think about it is as software, not as an AI-assisted editorial workflow.
What gets built is a codebase in an AI-assisted development environment, Cursor or equivalent, in Python or TypeScript. It lives in a repository, it is version controlled, it has tests and it ships. The coding assistant accelerates building it; it does not replace it.
A reasonable structure:
/sources ingestion adapters, one per data source
/schema the canonical data model and its validations
/rules templates, nomenclature glossary, explicit prohibitions
/golden reference articles written by a human specialist
/pipeline the transformation stages
/checks deterministic validators
/adapters publishing targets
/evals output compared against the golden set
The engine runs as a pipeline of stages, each with an inspectable output:
Ingestion and normalization. Adapters read each source and emit canonical records. No language model is involved here: this is parsing, mapping and type validation. If a catalog carries garbage, it surfaces here rather than thirty steps later.
Prioritization. The system crosses the taxonomies, drops combinations already covered and ranks the rest against defined criteria: estimated query volume, margin on the associated part, inventory availability, failure frequency in your own history. The output is a work queue, not an improvised list of headlines.
Drafting. Here the model enters, and it enters constrained. It receives the canonical record, the structural template, the nomenclature glossary for the target market and the prohibitions. Its job is to compose, not to recall. Hard data is injected as fields; it is never requested from the model.
Deterministic verification. Before any human sees anything, the article goes through checks that require no judgment and fail in binary fashion:
This stage is what makes volume possible. Every check that can be automated is human time freed for the parts that actually need judgment.
Human review. What survives reaches a review queue with the checks already resolved and the exceptions flagged. The reviewer is not fixing commas; they are judging whether the diagnosis is right and whether the article deserves to exist.
Rendering and publishing. The final stage converts the approved article into the target format and ships it.
That last point is worth insisting on, because it tends to inflate into a project phase and it is not one. Publishing is a thin adapter at the end of the pipeline. The target can be a commerce platform's admin interface, a headless CMS, a repository of markdown files feeding a static generator, or some combination. The pipeline does not change. The final adapter does, and it is usually a couple hundred lines of code. Designing the system around one specific platform makes it fragile for no reason.
One practice separates a maintainable system from one that degrades quietly: before generating anything, a human specialist writes ten to twenty reference articles by hand, covering the representative cases including the hard ones.
That set serves three purposes. It is the operational definition of "good": the template and rules are written to reproduce it, not the other way around. It is the regression test: every time a prompt or a rule is touched, or the model is swapped, output is compared against it and you can see what broke. And it is what lets a business change model providers without rebuilding the project.
Without a golden set there is no way to know whether a change improved the system or degraded it. You work on impression, and working on impression is how you end up publishing garbage without noticing.
The repository needs three things from its destination: an owned domain, stable URLs and the ability to update programmatically. Everything else is negotiable.
There is one line worth not crossing: hosting the content on someone else's domain, whether a third-party publishing platform or a blogging service, builds authority for the third party rather than for the business.
Within your own domain, the choice between subfolder and subdomain depends on the scenario. A subfolder, domain.com/guides/, is the sensible starting point for a single-brand business selling online: signals accumulate on one entity and commercial integration is native, because the product card, the session and the cart live in the same place as the article.
A subdomain makes sense when the commerce platform cannot support the structure the project needs without compromising performance, when volume calls for an independent stack with a static generator or headless CMS, when the repository serves several brands within one group, or when IT constraints rule out touching the root. Its cost is that it splits signals across two properties and forces you to solve internal linking and session and cart continuity toward the store separately.
The practical criterion: if content and catalog sell each other within the same session, use a subfolder. If the repository is an editorial product with its own infrastructure and lifecycle, use a subdomain with an explicit plan for linking and handoff to the store.
When a commerce platform's content module is used, rename the path with a term that declares what it holds rather than leaving the generic "blog": guides, diagnostics, technical manual. The name matters less than the consistency and depth of what sits behind it.
The structure is not an aesthetic decision. Each block serves a specific function for a different reader: the search engine, the language model and the person with the broken car.
The title combines symptom, fault code and vehicle platform, because that is how the user phrases the query. The opening paragraph delivers the complete answer in under fifty words: what the code means, what causes the symptom in most cases and which part resolves it.
That initial compression is what a search engine extracts for a featured snippet and what a language model uses as a synthesized answer. If the answer sits in paragraph eight, extraction never happens.
The table organizes information into a matrix of probable cause, characteristic symptom, replacement part and repair difficulty.
Language models process relationships. A table hands them the relationship already built, with no syntactic ambiguity to resolve. It is the format with the highest information density per token and the one most likely to be reproduced in a generative answer.
For the human reader it serves a different purpose: in three seconds they confirm or rule out their suspicion and know which part they need.
The part appears at the point in the text where the reader has just confirmed the diagnosis, not at the end. Placing the offer after two thousand words destroys conversion for someone who already decided in paragraph four.
The card carries the full part description, the compatible year and model range, the brand, the OEM reference number, the price and a direct link to the product page. It is contextual advertising with no media cost, served at the moment of maximum intent.
A sequence of verifiable steps demonstrates practical experience. It is the hardest signal to fake and the one that separates a specialist's content from a generic writer's.
It is also the format models extract verbatim when someone asks how to test for a fault. A well-built numbered list is a prefabricated conversational answer.
HTML is for people; structured markup is for machines. A JSON-LD block explicitly declares that the document is a technical article, which fault code it covers, which product it mentions, with which part number and from which brand.
This removes the interpretive margin. Instead of waiting for the system to infer what the content is about, you hand it the classification already resolved:
html
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "TechArticle",
"headline": "Code [OBD2 code] on [engine platform]: causes and fix",
"description": "Diagnosing and repairing [fault] on [engine platform].",
"about": {
"@type": "Thing",
"name": "OBD2 code [code]"
},
"mentions": [
{
"@type": "Product",
"name": "[Part description]",
"mpn": "[OEM number]",
"brand": { "@type": "Brand", "name": "[brand]" }
}
]
}
</script>
The markup is rendered from the same canonical record fields that feed the article body, never assembled separately. That is the only way to guarantee that what the text says and what the markup declares do not contradict each other.
Automation handles retrieval, assembly, formatting, validation and publishing. Judgment stays on the human side, and it is worth being explicit about where exactly:
Source selection and trust hierarchy. Which catalog wins when two disagree. That is a business decision and it does not get delegated.
Authoring the template, the glossary and the rules. The constraint system is written by someone who knows the market. A nomenclature glossary generated by the same model that will consume it constrains nothing.
The golden set. Written by hand, by a specialist.
Exception review. Anything failing a hard check goes to a person. It does not self-correct.
Batch sampling. With explicit acceptance criteria and a defect rate that, once exceeded, sends the whole batch back.
The decision not to publish. The most important one, and the one no automated system makes well. A topic covered badly, a data point you are not confident in, a discontinued part: those get dropped, and dropping is human work.
There is an asymmetry worth holding onto. Publishing one bad article costs more than not publishing ten good ones, because the damage is not confined to that page: it contaminates how the whole repository is perceived, by readers and by the systems evaluating it.
The reference articles get written by hand, the pipeline gets built and it runs against a small batch. The goal is not volume but calibration: getting the system's output publish-ready without intervention in the large majority of cases.
Publishing happens by hand, whatever the destination, and the content gets checked on the real site: how tables behave in the installed theme, how product cards behave on mobile, how the markup fares in the validator. Rules get corrected against the golden set until the comparison stops surfacing meaningful differences.
This phase is deliberately slow. Every defect not caught here gets multiplied by the scale factor of the next one.
The publishing adapter goes live and volume increases, but every article still passes through review before it ships. Human work speeds up because deterministic checks arrive already resolved, not because review disappears.
This is where the real per-article review cost surfaces, and where the system gets tuned to bring it down. The answer is almost always to tighten the rules or improve the input data, not to review faster.
Once the defect rate settles below the agreed threshold, review moves from exhaustive to sampled, with defined escalation criteria. A second agent gets built specifically for quality control, evaluating technical coherence and nomenclature consistency before a human steps in, acting as a pre-filter rather than as the final approver.
Data integrations get maintained, articles get updated when prices or cross-references change, and the eval suite runs every time the model or the rules are touched. This phase has no end date. It is the cost of keeping a living asset.
The metrics for this strategy are not the metrics of a paid campaign, and they do not mature in the first month.
In the short term you watch indexed content volume, appearances in featured snippets and impressions on diagnostic queries, kept separate from brand and product queries.
In the medium term what matters is citation in generative answers. This is measured by building a fixed set of representative queries and running them periodically against the major conversational assistants, recording whether the domain shows up as a source. It is a manual or semi-automated measurement, but it is the only way to know whether the strategy is working in the channel it was designed for.
Commercially, you measure assisted conversion: the share of sessions that enter through a technical article and end in a transaction, and the repository's contribution to total revenue.
One internal metric is worth tracking from day one: defect rate per batch and human review time per published article. If the first does not fall and the second does not give, the system is not scaling even if volume grows.
The architecture stays the same; what changes is the axis of the content.
A parts retailer organizes the repository around part number and fitment, with the direct sale as the destination.
A repair shop or service chain organizes it around symptom and procedure, with the service appointment as the conversion and explicit geographic segmentation.
A wholesale distributor organizes it around cross-references and availability, aimed at a professional reader buying in volume.
A component manufacturer organizes it around specification and failure mode, in order to install its own nomenclature as the market reference.
Phases one and two resolve within roughly three months, with room to move depending on how fast volume is meant to scale. Inference credit consumption is proportional to that speed and is the system's main variable cost, alongside specialist review hours.
Phase three is a permanent commitment: maintaining the engine, updating data, optimizing quality control and periodically revisiting the approach as search and assistant answer formats change.
What gets built is not a campaign, and it is not an archive of articles either. It is a production system with human judgment designed into it, and a body of verifiable content that is hard to replicate for a competitor without the data, the technical judgment and the infrastructure.
Strategy, design, content and growth.
