
How to Format Product Data for Your Fulfillment RFP
Learn how to structure product information in your 3PL RFP. Get templates, formatting guidance, and best practices for presenting product data that providers can actually use.
You have collected your product data. Dimensions, weights, fragility levels, handling requirements. You know what needs to be communicated.
Now you need to format it in a way that 3PLs can actually use.
The format matters as much as the content. Product data buried in paragraph form at the end of a 40-page RFP document will be skimmed or ignored. Data in an unsortable PDF will frustrate providers trying to build estimates. A 500-row spreadsheet with no grouping or context will overwhelm evaluators.
The goal is not to show providers everything you know about your products. The goal is to give them the specific information they need to assess capability fit and build accurate pricing — in a format they can work with.
This is the tactical guide to formatting product data for your fulfillment RFP.
Separate Attachment vs. Embedded in RFP Document
The first decision: should product data be a separate attachment or embedded within your RFP document?
Short answer: Separate attachment, always.
Why Separate Attachments Work Better
Providers need to manipulate the data
When a 3PL evaluates your products, they are not just reading. They are categorizing, sorting, calculating storage density, estimating labor time, and mapping products to their operational workflows.
If your product data is embedded in a Word doc or PDF, they have to manually re-create it in their own format. If it is in a separate Excel or CSV file, they can import it directly into their estimating tools.
It keeps your RFP document focused
Your main RFP document should tell the story of your business: who you are, how you sell, where you are going, what you need. Product data is reference material. It supports the narrative but does not belong inside it.
A clean separation keeps your RFP readable and your product data usable.
It scales with catalog complexity
If you have 10 SKUs, embedding product data in your RFP might work. If you have 100 SKUs, it creates a 15-page section that disrupts the flow of your document.
Separate attachments scale. Your RFP stays the same length whether you have 10 products or 1,000.
What to Include in Your RFP Document (High-Level Summary)
Even though product data lives in an attachment, your main RFP document should include a high-level product summary:
In the RFP document:
- Total active SKU count
- Product categories (apparel, glassware, packaged goods, etc.)
- General size ranges (small items under 1 lb, medium items 1-5 lbs, large items 5+ lbs)
- Any special product requirements (temperature control, fragile handling, hazmat)
- Reference to the detailed product attachment ("See Attachment A: Product Profiles for complete product data")
Why this works: It gives providers context before they dive into the detailed spreadsheet. They understand the big picture, then reference the attachment for specifics.
Recommended Attachment Format
Best: Excel or Google Sheets
- Sortable, filterable, can be imported into estimating tools
- Providers can add columns for their internal notes
- Formulas can calculate totals, averages, or category summaries
Acceptable: CSV
- Universal compatibility, works with any system
- Lightweight and easy to share
- Can be opened in Excel or imported into databases
Avoid: PDF
- Not sortable or filterable
- Data cannot be easily extracted or manipulated
- Creates extra work for providers
Never: Data embedded in Word document
- Impossible to sort, filter, or import
- Forces providers to manually re-enter data
- Signals lack of operational sophistication
One Profile Per SKU vs. Grouped Product Categories
The second decision: Do you create individual profiles for every SKU, or group similar products into categories?
Short answer: It depends on your catalog size and product similarity.
When to Profile Every SKU Individually
Use individual SKU profiles if:
- You have fewer than 50 SKUs
- Products vary significantly in size, weight, or handling requirements
- You have high-value or complex products that warrant detailed documentation
What this looks like (individual SKU format):
Each row in your spreadsheet represents one SKU with these columns:
- SKU: MUG-001
- Product Name: Ceramic Mug - Blue
- Dimensions (L x W x H): 4" x 4" x 5"
- Weight: 1.2 lbs
- Fragility: High
- Monthly Volume: 450 units
- Storage Temp: Ambient
- Special Handling: Bubble wrap required
Next row:
- SKU: MUG-002
- Product Name: Ceramic Mug - Red
- Dimensions (L x W x H): 4" x 4" x 5"
- Weight: 1.2 lbs
- Fragility: High
- Monthly Volume: 380 units
- Storage Temp: Ambient
- Special Handling: Bubble wrap required
Pros:
- Maximum precision for estimating
- No ambiguity about individual product requirements
- Easy for providers to spot outliers or high-complexity items
Cons:
- Time-consuming to create if you have a large catalog
- Can overwhelm providers with detail if most SKUs are similar
- Creates a long spreadsheet that requires scrolling
When to Use Product Categories with Representative Samples
Use product categories if:
- You have 50+ SKUs
- Many products are operationally similar (variants in color, size, or style)
- You want to simplify the RFP without losing accuracy
- You plan to add or change SKUs frequently
What this looks like (category format):
Each row represents a category with a representative sample:
Category 1: Standard Apparel
- Representative SKU: TSHIRT-MD
- Dimensions (L x W x H): 12" x 8" x 2"
- Weight: 0.6 lbs
- Fragility: Low
- SKUs in Category: 45
- Total Monthly Volume: 8,200 units
- Notes: All sizes 0.5-0.7 lbs, poly mailer
Category 2: Heavy Apparel
- Representative SKU: JACKET-LG
- Dimensions (L x W x H): 14" x 10" x 4"
- Weight: 2.1 lbs
- Fragility: Low
- SKUs in Category: 12
- Total Monthly Volume: 1,800 units
- Notes: Jackets, hoodies; box required
Pros:
- Simplifies large catalogs without losing operational accuracy
- Focuses provider attention on category-level characteristics
- Easier to maintain as SKUs change
Cons:
- Less precision for individual SKU estimates
- Providers may need to request additional detail on outliers
- Requires clear category definitions to avoid confusion
Hybrid Approach: Categories + Individual Hero Products
For many brands, a hybrid approach works best.
How it works:
- Profile hero products individually (products representing 60-80% of volume)
- Group low-velocity SKUs into categories with representative samples
Individual Profiles (Hero Products section):
Hero Product 1:
- SKU: HERO-001
- Product Name: Bestselling T-Shirt
- Dimensions: 12" x 8" x 2"
- Weight: 0.6 lbs
- Fragility: Low
- Monthly Volume: 4,200 units
Hero Product 2:
- SKU: HERO-002
- Product Name: Signature Hoodie
- Dimensions: 14" x 10" x 4"
- Weight: 1.8 lbs
- Fragility: Low
- Monthly Volume: 2,800 units
Category Profiles (Long-Tail Products section):
Category: Seasonal Apparel
- Representative SKU: SEASONAL-001
- Dimensions: 12" x 8" x 3"
- Weight: 0.8 lbs
- SKUs in Category: 28
- Monthly Volume: 600 units total
Category: Accessories
- Representative SKU: ACCESS-001
- Dimensions: 6" x 4" x 2"
- Weight: 0.3 lbs
- SKUs in Category: 35
- Monthly Volume: 450 units total
Why this works:
- Providers get precise data where it matters most (high-velocity products)
- You avoid overwhelming them with 200 individual SKU profiles
- Low-velocity products are documented without excessive detail
What Level of Detail to Include (Without Overwhelming Providers)
The third decision: How much detail is enough, and when does it become too much?
Guiding principle: Include what affects operational decisions. Exclude what does not.
Always Include (Core Operational Data)
These fields are non-negotiable. Every product profile needs them:
- SKU identifier - Unique code to reference the product
- Product name - Human-readable description
- Dimensions (L x W x H) - As stored and/or as shipped
- Weight - As stored and/or as shipped
- Monthly volume - Units shipped per month (or annual volume divided by 12)
- Fragility level - Low, Medium, High (or similar scale)
Why these matter: These six fields allow a provider to estimate storage space, pick labor, packing labor, and material costs. Without them, they cannot build an accurate proposal.
Include When Relevant (Product-Specific Requirements)
Add these fields only when they apply to your products:
- Storage requirements - Ambient, climate-controlled, refrigerated, frozen
- Special handling - Bubble wrap required, orientation matters, two-person lift, etc.
- Kitting or bundling - Percentage of orders that include this SKU in multi-item orders
- Value-added services - Gift wrapping, inserts, custom packaging, assembly
- Expiration or lot tracking - Whether the product requires date or batch management
- Regulatory or compliance - FDA, USDA, hazmat classification, alcohol shipping
Why these matter conditionally: Not every brand needs climate control or lot tracking. But if you do, providers need to know. These fields filter capability fit (can they do it?) and affect cost (how much does it cost?).
Rarely Include (Detail That Does Not Affect Operations)
Providers do not need:
- Marketing copy or product descriptions
- Material composition (unless it affects handling, like "fragile ceramic")
- Color or style details (unless variants have different dimensions or weight)
- Retail price or MSRP
- Supplier information
- Barcode or UPC (unless required for compliance)
Why these do not matter: They do not affect how the product is stored, picked, packed, or shipped. Including them clutters the spreadsheet without adding value.
Visual Detail: When to Include Photos
Photos add value when:
- Products are unusually shaped or awkward to handle
- Fragility is not obvious from dimensions alone (thin plastic that looks sturdy)
- Packaging is complex or custom
- You need to show the difference between storage state and shipping state
How to include photos:
- Option 1: Separate photo attachment labeled by SKU (e.g., "SKU-001-storage.jpg", "SKU-001-packed.jpg")
- Option 2: Hyperlinks in your spreadsheet pointing to cloud-hosted images
- Option 3: Embedded thumbnails in Excel (only if file size stays reasonable)
When photos add more noise than signal:
- All products look similar and dimensions tell the full story
- Products are standard shapes (apparel, books, boxes)
- You have 100+ SKUs and photographing everything is not realistic
Photos should clarify, not decorate. If dimensions and fragility notes are sufficient, skip the photos.
Formatting Best Practices for Your Product Data Spreadsheet
Once you have decided on individual vs. category and determined your level of detail, follow these formatting best practices:
Structure Your Columns Logically
Left to right, most important to least important:
- SKU identifier
- Product name
- Category (if using categories)
- Dimensions (L x W x H)
- Weight
- Monthly volume
- Fragility
- Storage requirements
- Special handling
- Notes
This order lets providers scan the most critical information first without scrolling horizontally.
Use Consistent Units
Pick a unit system and stick to it:
- Dimensions: All inches, or all centimeters (not a mix)
- Weight: All pounds, or all ounces, or all kilograms (not a mix)
- Volume: All units per month (not a mix of monthly and annual)
Inconsistent units create confusion and estimation errors.
Add Data Validation and Drop-Downs
If you are using Excel or Google Sheets, add drop-downs for standardized fields:
- Fragility: Drop-down with "Low", "Medium", "High"
- Storage requirements: Drop-down with "Ambient", "Climate-Controlled", "Refrigerated", "Frozen"
- Special handling: Drop-down with common options or free text
This prevents typos and ensures consistency.
Include a Summary Row at the Top
Add a summary row that calculates:
- Total SKU count
- Total monthly volume (sum of all units)
- Average weight
- Percentage by fragility level
- Percentage by storage requirement
This gives providers a quick snapshot before they dive into individual rows.
Use Conditional Formatting to Highlight Complexity
Use color coding to draw attention to high-complexity products:
- Red highlighting for fragile items
- Orange highlighting for items requiring special storage
- Yellow highlighting for high-volume SKUs
This helps providers quickly spot operational complexity.
Add a Notes Column for Context
Include a free-text "Notes" column where you can add context that does not fit other fields:
- "Frequently ships in 2-packs"
- "New product launching Q4, volume projection is estimate"
- "Currently over-packaged, open to more efficient packaging"
Notes should be concise (one sentence) and used sparingly.
Common Formatting Mistakes That Frustrate Providers
Burying Product Data in Narrative
Bad example: "Our products range from small apparel items around 12 inches by 8 inches weighing half a pound up to larger items like our signature jacket which is 14 inches by 10 inches and weighs about 2 pounds, and we also carry some fragile glassware..."
This is unworkable. Providers cannot build estimates from prose. Use structured data.
Mixing Storage and Shipping Dimensions Without Labeling
If you include both storage dimensions and shipping dimensions, label them clearly:
- "Dimensions (Storage)" vs. "Dimensions (Shipping)"
- Or separate columns: "Storage L x W x H" and "Shipping L x W x H"
Ambiguity creates estimation errors.
Including Inactive or Discontinued SKUs
If a product is no longer sold, do not include it in your product data. It wastes provider time and inflates your SKU count artificially.
If a product is being discontinued but still has inventory to fulfill, note it: "Discontinuing Q1 2026, ~200 units remaining."
Inconsistent Category Definitions
If you use categories, define them clearly. Do not make providers guess whether "Standard Apparel" includes hoodies or if hoodies belong in "Heavy Apparel."
Include a category definition tab or section that eliminates ambiguity.
Overloading with Variants That Are Operationally Identical
If you sell a t-shirt in 10 colors and all colors have identical dimensions, weight, and handling, do not create 10 rows.
Create one row and note: "T-Shirt (all colors) - 10 SKUs" with combined monthly volume.
The exception: If different colors have different velocities that matter for storage planning, list them separately.
How Providers Use Product Data in Their Evaluation
Understanding how providers use your product data helps you format it effectively.
Storage Estimation
Providers calculate cubic feet required based on dimensions, then factor in storage density (how tightly products can be packed).
What they need: Dimensions (as stored), monthly volume, whether products can be stacked or must be stored flat.
Labor Estimation
Providers estimate pick and pack labor based on product size, weight, fragility, and any special handling.
What they need: Weight, fragility level, special handling requirements, percentage of orders that are single-SKU vs. multi-SKU.
Material Cost Estimation
Providers calculate packaging material costs based on what each product requires.
What they need: Whether products ship in retail packaging or require boxes, protective materials needed, box sizes.
Capability Filtering
Before they even estimate cost, providers check: Can we handle this?
What they need: Storage temperature requirements, compliance needs (hazmat, FDA), special equipment requirements (two-person lift, climate control).
Formatting your product data to make these four evaluations easy makes their job easier and your proposals more accurate.
Product Data Formatting Is About Usability, Not Completeness
The goal is not to document everything you know about your products. The goal is to give providers the specific information they need, in a format they can use, to assess fit and build accurate proposals.
Separate attachments over embedded data. Structured spreadsheets over narrative prose. Core operational fields over marketing detail. Categories when appropriate, individual profiles when necessary.
Format for usability. Providers will thank you with better, faster, more accurate proposals.
Providers need precise data for accurate storage and labor estimates