Start a Product Catalog Cleanup Service

A product catalog cleanup service sells a reviewed correction batch—not an unlimited promise to fix an online store. The viable starting point is one platform, one product category and a clear rule for who approves every uncertain fact.

Verdict: Conditional. This can be an asset-light service business when customers have usable source information and will pay for specialist review. It is a weak model when missing facts require endless investigation, clients expect guaranteed sales growth, or every batch needs the founder to make judgment calls.

Choose the buyer and the problem you will own

Start with a merchant whose catalog manager has a defined backlog: inconsistent category values, mismatched attributes or product records that no longer agree with approved supplier information. A merchant without a current source of truth is not simply a larger cleanup job; it may need a different discovery project.

The buyer should be able to name both a budget owner and a product-fact approver. Ask what happens today when an attribute is disputed, how often new supplier files arrive, and what work is delayed by the backlog. “Our spreadsheet is messy” is not enough evidence of willingness to pay.

Alternatives include the merchant’s own staff, a general assistant, a specialist agency and catalog-management software. Your offer must explain what reviewed output the customer receives that those alternatives are not currently delivering. Do not promise a conversion lift or search-ranking improvement you cannot substantiate.

Write a bounded offer before quoting by SKU

A stock-keeping unit, a product and a variant family are not interchangeable units of effort. Agree on the counting rule before discussing price. A product with multiple sizes, colors and conflicting source files may require much more work than a simple record.

Use this initial offer canvas as a planning template, not a market-standard package:

• Customer: one merchant using one agreed Shopify export format.
• Batch: up to 100 explicitly identified records, with variant relationships listed separately.
• Included fields: a named set, such as category and approved attribute vocabulary. Prices, stock levels and product claims remain excluded unless separately contracted.
• Sources: the merchant’s dated export, approved supplier documents and a signed-off field dictionary.
• Deliverables: corrected file, per-change evidence ledger, unresolved-issue register and review summary.
• Acceptance: the named reviewer approves the specified checks; source conflicts remain visible rather than silently guessed.
• Boundary: the merchant performs the import unless you have separately agreed access, testing, approval and recovery responsibilities.

Separate mechanical normalization from factual correction. Standardizing an approved color value is different from deciding what material a product contains. A missing dimension, certification or safety claim must go back to an authorized source; it is not an invitation to generate plausible text.

Make the import boundary explicit

Shopify’s product CSV documentation explains the file format and field dependencies, including dependencies involving variant options. It warns that omitting required option information can create a default variant and delete existing variants. A syntactically valid spreadsheet is therefore not sufficient acceptance evidence.

For an initial offer, deliver a reviewed file and have the merchant approve a small test before any wider import. Preserve the original export and agree a recovery approach in the merchant’s environment. Never call an export a complete store backup. Import execution, app interactions and platform-specific recovery require their own expertise and scope.

Recruit for exception judgment, not typing speed

You need a product-data specialist who understands the chosen platform and a reviewer who can detect incorrect changes. At pilot scale the founder may fill one role, but cost that time. Do not pretend a provider network removes management work.

Use a paid test containing a duplicate-looking pair, a conflicting source value, a missing attribute and a variant family. A strong specialist flags uncertainty instead of merging or inventing values. Evaluate source traceability, consistency and reviewability—not just rows completed per hour.

Agree availability, revision responsibility, confidentiality, access permissions and payment terms before assignment. Keep customer files separated, share only necessary data and remove access when the engagement ends. Have relevant local advisers address business setup, contracts, insurance and worker arrangements; do not assume using contractors resolves those obligations.

Price review and exceptions into the batch

These figures are a constructed planning example, not current market rates, an earnings claim or a recommended quote. Replace them with paid-test measurements and actual supplier quotes.

This is contribution before fixed overhead, acquisition costs, taxes and owner profit. At these assumptions, four extra specialist hours cost $100 and reduce contribution to $50. Six extra hours consume the entire $150 contribution. That sensitivity is the reason to inspect source quality before quoting.

Use a paid diagnostic or smaller pilot when the exception load is unknown. Define a change-order trigger for added fields, additional channels or new source research. Ongoing maintenance should follow demonstrated recurring work, not a retainer sold before you know the workload.

Run a paid test with stop rules

Use the following experiment as a founder-set decision rule. Its thresholds are illustrative choices, not industry benchmarks.

1. Hypothesis: a narrowly defined merchant segment will pay for a source-linked correction batch instead of buying general assistant hours.
2. Test: interview ten relevant merchants, inspect permissioned sample files and offer the same bounded paid pilot to those with a suitable backlog.
3. Signal: record paid commitments, objections, actual labor by stage, unresolved facts and reviewer acceptance. Compliments and sample requests are not purchases.
4. Threshold: proceed only after two independent customers buy and both pilots meet your preselected contribution floor, with no unapproved factual changes. For example, use a 25% contribution floor only if it also covers your business’s remaining costs at realistic capacity.
5. Decision: continue if payment and delivery evidence agree; narrow or reprice if exception work breaks the economics; stop if buyers will not pay, source facts cannot be verified or review cannot prevent unauthorized changes.

For discovery, approach merchants through relevant professional relationships and ecommerce implementation partners. A useful question is: “Which catalog fields consume repeated review time, and who can approve the correct value?” Ask permission before accessing files. This is an interview prompt, not a reason to scrape or change a prospective customer’s store.

Make every correction traceable

Copy this ledger schema into your pilot specification:

batch_id | record_id | variant_family | field
old_value | proposed_value | source_reference | source_date
reason | specialist | reviewer | customer_approval
exception_owner | decision | approved_file_version

For example, if two supplier sheets disagree on a product dimension, log both references, leave the proposed value unresolved and assign the merchant’s product owner. Do not let “review complete” disguise a missing decision.

Use a delivery flow with explicit transitions: received → scope approved → assigned → corrections prepared → independent review → customer decision → approved delivery → closed. Failed review returns to the specialist; missing evidence moves to a customer-information queue. Cancellation closes the batch with work completed, access removal and billing handled under the contract. A changed source file creates a version decision, not an invisible overwrite.

Build this business in Workhint

The service needs a coordination layer, not a claim that one tool can repair every catalog. Workhint’s Workflow Engine describes configurable requests, assignments, role-based approvals and requirements for details or files before work progresses. Its Founders solution describes separate customer, worker and admin journeys for work-based marketplaces.

Use those supported building blocks to design the batch service. Keep CSV editing, platform validation and imports in the agreed external tools; these sources do not establish a native Shopify connector or automated catalog correction. If you are still deciding between a specialist business and broader support, compare the general virtual-assistant agency model before widening the offer.

Copy-ready builder brief

Design a catalog-cleanup service workflow for merchants, product-data specialists, reviewers and an operator. Customers submit platform, category, batch count, variant-family scope, allowed fields, approved sources, deadline and named fact approver. Require scope approval and source files before assignment. Onboard specialists with platform experience and a reviewed test; operators match work to qualifications and availability.

Use the states received, scope approved, assigned, corrections prepared, independent review, awaiting customer information, customer decision, approved delivery, cancelled and closed. Require an evidence-ledger file and proposed output version before review. Route rejected work to the specialist and disputed facts to the customer’s approver. Keep customer and provider access separate. Let operators handle deadline changes, unavailable reviewers, cancellations and revised source files. Record acceptance and approved delivery evidence. Track batch age, labor, exception count, rework and contribution using reviewed pilot records. Keep import execution and billing in separately approved external processes for this pilot; do not assume integrations or payment automation. Test permissions and each exception path before live customer use.

This is a configuration brief to validate, not proof that a finished application or every requested metric is available without further setup.

Scale only when a second person can deliver the standard

Launch with the narrow paid batch and track its real bottleneck. Add capacity only when another specialist can follow the field dictionary, another reviewer can reproduce the acceptance decision, and exceptions no longer require the founder to interpret every row.

Expand one dimension at a time: more volume, another product category or another platform—not all three. Each new channel adds its own schema and acceptance work. If customers mainly need missing-source investigation, change the business model rather than hiding that work inside cheap per-record pricing.

FAQ

Can I start without employees?

You can test with founder delivery and contracted specialist capacity, but review, customer accountability and local worker requirements still need owners. No employees does not mean no labor cost.

Should I charge per SKU?

Only after defining the counting unit and measuring complexity. A bounded batch with named fields and exception rules is easier to evaluate than a single price applied to every variant family.

Can AI fill missing product information?

Not as an authoritative source. Any suggested factual value needs approved evidence and review. Leave unresolved facts visible rather than fabricating attributes to complete the file.

What is the first thing to validate?

Whether a real buyer will pay enough for a reviewed, limited batch to cover specialist work, review, coordination and rework. Build a larger operation only after that evidence exists.