01 / Use case
Use this page when an agency needs to hand Qurifix work to a client.
Qurifix delivery should feel concrete: what was tested, what evidence was missing, which repairs are ready to publish, and what changed after retesting. The agency role is to translate diagnosis into client decisions without overstating what answer engines or marketplaces can be forced to do.
02 / Checklist
Delivery checklist
Package the work so the client can approve, publish, and retest without hunting through raw notes.
- Audit snapshot: SKU URL, market, primary competitor set, prompt set, test date, and source assumptions.
- Executive diagnosis: the one-page explanation of why the product evidence is underperforming.
- Evidence gap list: missing, inconsistent, weak, or hard-to-extract signals across PDP, listing, FAQ, schema, feed, and comparison surfaces.
- Fix Pack assets: publishable copy blocks, FAQ answers, listing bullets, schema or feed notes, and comparison language.
- Approval log: which claims the client approved, rejected, edited, or needs to substantiate before publishing.
- Delivery readiness: confirm the workspace readiness score, client share link, open Fix Pack assets, and next retest date before handoff.
- Publication record: publish date, target URL, owner, and notes on what changed.
- Retest summary: same-prompt comparison, observed movement, remaining uncertainty, and monitoring recommendation.
03 / Client meeting
Client meeting flow
Keep the meeting decision-led. The goal is not to walk through every audit artifact; it is to align the client on evidence gaps, repairs they can publish, and the boundaries of the work.
| Step | Agency lead | Client decision |
|---|---|---|
| 1. Frame the baseline | Show SKU, prompt set, competitor set, and the answer-quality problem. | Confirm the test scope matches the commercial priority. |
| 2. Explain the evidence gap | Group findings by fit, trust, comparison, availability, policy, and structured data. | Agree which gaps are real, material, and publishable. |
| 3. Review Fix Pack assets | Present approved-ready copy separately from claims needing proof. | Approve, edit, reject, or assign substantiation owners. |
| 4. Set the publishing plan | Map assets to PDP, marketplace listing, FAQ, schema, feed, and comparison pages. | Confirm owners, dates, platform constraints, and QA checks. |
| 5. Commit to retest | Define when the same prompts will be retested after changes are live and crawlable. | Approve the retest window and success signals. |
04 / Template
Copyable report structure
Use this structure for a client-facing deck, memo, or shared document.
- Executive summary: one paragraph on the commercial problem, the audit scope, and the highest-priority repair.
- Baseline scope: SKU, market, prompt set, competitor set, source notes, test date, and assumptions.
- What answer engines could explain: product facts that were clear, extractable, and consistent.
- What answer engines struggled to explain: missing proof, conflicting claims, weak comparison language, unclear policies, or thin FAQ coverage.
- Prioritized repair queue: critical, high, and medium repairs with owner, surface, and publishing effort.
- Fix Pack assets: approved copy blocks and implementation notes grouped by surface.
- Boundary statement: no ranking guarantees, no fake reviews, and evidence-based repair only.
- Retest plan: when the retest will run, which prompts will be reused, and which signals will be compared.
- Appendix: screenshots, source URLs, rejected claims, and client substantiation notes.
05 / Publishable assets
Fix Pack handoff
A Fix Pack should be easy for the client to publish and easy for an agency to QA. Each asset needs a target surface, a claim basis, and a note on what should not be changed without approval.
| Asset | Handoff detail | QA check |
|---|---|---|
| PDP repair block | Placement guidance, final copy, claim source, and internal owner. | Matches approved facts and does not create unsupported claims. |
| FAQ answers | Question, answer, buyer objection, and proof note. | Answers real objections directly and avoids vague marketing language. |
| Marketplace listing bullets | Character-aware bullets mapped to platform constraints. | Consistent with PDP, policies, and review themes. |
| Schema or feed notes | Fields to verify, update, or align with visible page evidence. | Price, availability, shipping, returns, and attributes do not conflict. |
| Comparison language | Fair-fit positioning against named or category competitors. | States where the SKU is strong without fabricating competitor claims. |
06 / Retesting
Retest readout
Retesting is the proof loop. Agencies should report observed signal movement without turning it into a promise. Use the same or clearly comparable prompts, market assumptions, and competitor set.
- State when repairs went live and when the retest was run.
- Compare baseline and retest answer quality, SKU mention, citation usefulness, and product-fit explanation.
- Call out changes that are directional, noisy, or blocked by crawlability, marketplace restrictions, missing proof, or model volatility.
- Recommend whether to monitor, publish a second repair wave, or close the project.
07 / Trust rules
Client-safe boundaries
Put these boundaries in the proposal, the report, and the final readout. They protect the client, the agency, and the usefulness of Qurifix work.
- No ranking guarantees. Qurifix does not guarantee rankings, placements, mentions, sales, revenue, platform approval, or model behavior.
- No fake reviews. Do not create, imply, purchase, rewrite, or simulate reviews, ratings, testimonials, or customer claims that did not happen.
- Evidence-based repair only. Repairs must be grounded in real product facts, visible policies, supported specs, review themes, tests, certifications, or other publishable proof.
- No claim laundering. If a claim needs substantiation, keep it in the approval log until the client provides support.
- No replacement for fundamentals. Product quality, price, inventory, fulfillment, policy, and customer experience remain outside the repair pack.