How to use this document: this is a generic, vendor-neutral scope
document. Fill in the bracketed fields, remove this instruction box, and
send it to any vendor(s) you want a comparative quote from. Nothing in
this document identifies who built the reference implementation it is
based on.
1. Project summary
We operate a retail/wholesale catalog of [ total item count ]
items and are evaluating vendors to build (or extend) a combined
e-commerce storefront and internal inventory-management platform. This
document specifies the full functional scope we require, organized by
function and by page, so that competing quotes can be compared
line-for-line rather than as vague bundled estimates.
A working reference implementation covering this exact scope already
exists and has been demonstrated to us. We are issuing this RFP to obtain
comparative pricing, not because the scope is undefined.
6. Data preparation work โ priced separately, per item
This is the part of the project that is not a fixed software build
and should not be estimated by development hours. It is data-entry
and classification work on a large, uneven catalog, and its cost scales
with item count, not with time โ a vendor who prices this by the hour has
no incentive to be efficient, and a vendor who prices it by time-boxed
phases has no way to guarantee completeness. Price it per piece.
6a. Categorization
Items already categorized: [ 27,132 ] (reference)
Items remaining to categorize: [ ~33,000, to reach a 60,000-item total catalog ]
Categorization = assigning each catalog item (currently identified only by barcode/SKU) into the correct product taxonomy (category โ subcategory), so it becomes browsable and searchable on the storefront.
6b. Enhancement
Items already enhanced: [ 575 ] (reference)
Items remaining to enhance: [ total catalog โ 575 ]
Enhancement = deduplication across near-identical listings, plus attaching manufacturer datasheets and full technical specifications to an item beyond its basic name/category โ a materially deeper level of work than categorization alone, and should be priced as a separate, higher per-item rate.
6c. Product imagery
Items with a usable photo today: [ 0 ]
Items with a correlated match against the client's own prior public catalog (~1,600 products, ~10,000 images, historical partial archive): [ ~180 by exact product code โ pending client approval to use ]
Requested quote: $ [ price per item ] ร item count needing a newly sourced photo
The client's own prior public site is a partial source: a code-based match against its archived pages recovers a small minority of the current catalog, not a majority โ treat it as a modest head start, not a substitute for real sourcing. Subject to the client's confirmation that reuse of its own prior product photography is permitted. Everything beyond that correlated set needs sourcing: client-supplied photos, manufacturer/distributor stock imagery, or new photography โ priced per item like categorization and enhancement above, since it scales with item count, not build time.
[ $ ]categorization, per item
[ $ ]enhancement, per item
[ $ ]imagery, per item
[ $ ]platform build, total
7. What a comparable vendor quote must include
A price for the platform build, covering every function listed in sections 2โ5 above โ not a subset, and not "similar functionality," the same scope.
A separate, per-item price for categorization work (section 6a), independent of the platform price.
A separate, per-item price for enhancement work (section 6b), independent of both the platform price and the categorization price.
Confirmation of what "done" means for each catalog item at each tier (uncategorized โ categorized โ enhanced) โ ambiguity here is the most common source of scope disputes on data-preparation contracts.
Ongoing hosting/maintenance terms, if the vendor is also proposing to operate the platform post-launch, quoted separately from the one-time build cost.
Any AI/assistant-related running costs (if the proposal includes an AI shopping assistant, product-description generation, or similar), quoted as an ongoing operational cost, not folded into the one-time build price.
8. Reference implementation
A live, working system meeting this full scope has already been built and
demonstrated. Vendors may reasonably assume this scope is achievable
within a normal commercial engagement, since it has already been done
once. This RFP is being used to obtain comparative pricing on that same
scope, not to test technical feasibility.