A capability annexe for teams evaluating Quire. Written to be checked rather than admired — every claim describes something running today, and the last section lists what isn't built yet, because you would find out anyway and it is cheaper for both of us if you find out now.
Quire does not start from a topic. It starts from a thing that happened inside your business, and works forward from the evidence.
Every proposed story arrives with its readiness, its score, the number of independent evidence fragments behind it, the content pillar it belongs to, the format it suits, and a one-line argument for why it is worth your reader's time. You can open the evidence before you approve the piece — which is the difference between reviewing a proposal and being handed a finished article you have to fact-check backwards.
Tier 1 means ready to write from what already exists. Tier 2 means one conversation is missing, usually with the person who did the work. Tier 3 means the evidence is thin and the story should wait. A tier describes what a story needs, not what format it becomes — every story you approve produces the same full package regardless of tier.
What a finished package contains
| Blog post | Written against your configured house style and the structural form for that pillar, with an SEO and internal-linking pass applied before publication. |
| LinkedIn post | Written from the published article rather than from the same brief, so it argues the piece rather than summarising it. |
| Feature image | Generated to your brand's design voice, cropped to your configured aspect ratio. |
| Inline diagrams | Two or three per post, where the argument has structure worth drawing. |
| Review document | A shared doc per piece, so edits happen where your team already comments. |
| Publication | HubSpot, WordPress, Drupal, or a generic webhook into whatever you run. |
About nine minutes of machine time per finished package. The constraint on your side is not production — it is the person who says yes.
Everything in the previous section assumes you have raw material. Plenty of companies don't — no CRM worth mining, no written delivery record, a team that has never published. That is a starting point, not a disqualification.
When there is nothing to read, we work the other way around. Before Quire reads anything, we build the content strategy with you: what you are actually for, which arguments you intend to own, who you are arguing with, and what your buyers are already asking. That engagement becomes Quire's input — it is the raw material, authored deliberately rather than mined.
Content pillars and the reasoning behind them · positioning and messaging · your named competitors and the arguments worth taking with them · an ideal customer profile and the questions it actually asks · a house style · a first calendar with the sequence argued rather than assumed.
What Quire can do from day one with no internal corpus at all
Rather more than you would expect. The discoverability audit needs nothing but your domain. The answer-engine gap map is built from your services, your market and your competitors — all public. And strategy-led pieces, the ones that argue a position rather than recount an engagement, do not require first-hand material, so they can be written immediately.
What it still will not do
Invent the engagement story you do not have yet. Client stories and practitioner deep-dives wait until there is something real behind them — which is the same refusal described later in this document, applied to your own starting position rather than to a single piece.
The corpus builds itself once you start. Decisions get written down because something is now reading them. Calls get transcribed. Pieces get published, and what happened next becomes evidence too. Month six has material that month one did not, and the engine moves onto it as it appears — which means the strategy engagement is a runway, not a permanent substitute.
Two different things are usually collapsed into the word "voice", and separating them is what makes output specific rather than merely competent.
Subject is what a piece is about, governed by the content pillars you set during onboarding. Form is how a piece is built: what the opening has to establish, what evidence the middle owes the reader, how it closes. Quire treats these as independent axes, so an engagement story and a technical deep-dive differ in structure, not only in subject matter. The same underlying event can legitimately become either.
Form rules resolve field by field, in precedence order, so one deliberate override never forces you to restate everything else:
| Manual | A rule you set explicitly for your workspace. Beats everything below it. |
| Pack | An authored structure for a specific kind of piece. |
| Learned | Reserved for shape inferred from your own published archive. Not built yet — see section 08. |
| Baseline | Reserved for a starting profile derived at onboarding. Not built yet. |
| Floor | Universal quality rules that apply to everything, always. |
Your configured voice settings today shape your discoverability copy and your visual design voice — they are read directly by the page-fix writer, the answer-engine content auditor and the image generator. Long-form articles are written against an authored house style plus the resolved form for that pillar.
Set expectations honestly here. Quire will not sound like your best writer in week one, because it has not read your archive yet — that layer is designed and reserved for, not built. What it will do from week one is be specific: the piece will contain the decision, the constraint and the number, which is the part generic tools cannot fake and the part editing cannot add afterwards.
If your best stories involve clients, the hardest part of publishing them is not the writing. It is being certain, every time, that you were allowed to say the name.
Most tools handle this with an instruction in a prompt — "do not name unannounced clients" — which works until the day it doesn't, and fails silently when it fails. Quire decides it in code, per client, before any writing instruction is assembled.
1. A guard runs first, on every surface: any label that merely
contains a known client name is refused outright — including derived slugs and
project codenames that happen to embed one.
2. Then context decides. A confirmed, live relationship may be named. An
open pursuit may never be named, regardless of how well the story reads or how senior the
person asking.
3. Where a story touches more than one relationship, verdicts combine
conservatively — the most restrictive wins.
4. Where a client cannot be named, the anonymisation is specified: not just
the name, but the giveaways. Sector vocabulary, geography, anything that would let a reader
reconstruct it.
Two properties make this worth more than a policy document. First, it is a one-way ratchet: any part of the system may make a client less nameable, and nothing may make one more nameable. Second, no writing instruction is permitted to know your client list at all — a prompt that knows the accounts can form its own opinion and quietly contradict the rule, so the rule reaches the writer as an already-resolved verdict, and an automated check fails the build if the two ever disagree.
Why it is built this way. An earlier version kept the rule in two places. They drifted, and the reviewer began rejecting correct drafts on confidentiality grounds that no longer matched the actual policy. Nobody noticed for weeks — because rejected work looks like caution rather than a bug.
A crawl tells you that 340 pages have a problem. That is a list, not work. Quire turns each finding into the specific change somebody can make this afternoon.
Per page
Per dead URL
A destination chosen deterministically from your live sitemap by matching path structure and slug words — then fetched and confirmed live before it is offered. Where no honest destination exists, the finding says so and proposes retiring the URL properly. It will never point at your homepage, which search engines treat as a soft 404 and which destroys the link equity the redirect existed to preserve.
Per issue class
For everything a page rewrite cannot fix — canonicalisation, crawl budget, redirect chains, structured data, render blocking — one plan per issue rather than one line per affected page: a diagnosis naming what the affected pages have in common, the ordered steps, the owner, the effort, and what it costs to leave alone. Every URL cited in a plan is checked back against the crawl and dropped if it does not exist.
Up to 1,500 pages per run, with a thousand affected rows examined per issue. Progress is persisted, so a long run survives a restart. The whole report exports as a single self-contained file with no external dependencies — forward it to whoever owns the site, or print it.
An increasing share of buyers never reach a results page. They ask an assistant, get three named options, and pick one. If you are not among the three, your ranking is irrelevant.
Quire generates the questions your buyers actually ask — derived from your services, your ideal customer profile and your named competitors — then scores where you stand on each: cited by name, merely mentioned, or invisible. It records which competitors were named instead of you, and in what order.
Be clear on what this is. These are model-simulated answers, not scraped live results from any specific assistant. It is a reliable signal of how a model reasons about your category given what is publicly written about you, and it is how you find the questions where you have no presence at all. It is not a citation tracker, and we will not describe it as one.
Gaps, classified
| Competitive | Competitors are cited on this question and you are not. Somebody else's content is answering it. |
| Opportunity | Nobody is cited well. The question is open, and the first credible answer tends to take it. |
| Quality | You are cited, but weakly or in the wrong position. The page exists and is underperforming. |
Gaps are prioritised by where the question sits in the buying journey, how crowded it already is, and how close it is to something you actually sell — so the list is ordered by what is worth writing, not by search volume.
It also audits what you have already published. Existing posts are assessed for whether a model could extract and cite them, and the fixes can be written back into your CMS through an approve, reject and re-verify loop. Nothing changes on your site without a human accepting it, and the change is checked again afterwards.
Beyond individual pieces, Quire can define and run a repeatable go-to-market motion for a segment you care about.
You describe the motion — a market, an audience, the sequence of work — or upload a document describing it. Quire turns that into a structured, editable definition: the roles involved, what each one produces, what it needs as input, and how outputs hand off between them. The definition is saved, refinable and runnable, and you can see what each run produced and where it passed work along.
In practice this is how a vertical play gets built once and then executed repeatedly by people who did not design it — research feeding positioning, positioning feeding content, content feeding outreach — without that chain living in one person's head.
A tool that refuses to overstate its output should not overstate itself either. All of the following is true today.
| Two formats have dedicated writers | Long-form articles and LinkedIn posts are purpose-built. Other formats — case study, landing page, video script, short social — are approximated from the nearest writer, and each piece is labelled as approximated rather than quietly passed off. Expect to edit those more. |
| House style is configured, not learned | Quire does not yet infer style from your own published archive. You get what you configure, plus a strong default. |
| No published-performance analytics | Quire reports what it proposed, wrote and published, and who the stories were about. It does not pull traffic, impressions or conversions back from your analytics. |
| Source coverage | CRM, internal documentation, meeting transcripts, your website and your published archive. Shared-drive documents and issue trackers are not yet ingestion sources. |
| Onboarding is hands-on | Setting up a workspace is done with us rather than self-service. A real constraint on how fast you start — and also where the quality comes from. |
Why print the previous page. Every item on it is something you would discover in the first month. Discovering it in month one, from a document, is a conversation about priorities. Discovering it in month two, after a claim on a slide, is a conversation about trust.
The discoverability audit needs nothing but your domain, so it is the sensible first step — you can judge the quality of the thinking before granting access to anything.
| Step one | We run the full audit against your live site and walk you through what came back. No access, no integration, no commitment. |
| Step two | If the thinking holds up, we connect read-only access to the systems where your work lives, and run one scan to see what is genuinely there. |
| Step three | One onboarding session to set content pillars, house style and approvers. Then a first package, start to finish, so you judge the real output rather than a sample. |
Commercials