GSA platform purpose map
GSA systems follow the contract lifecycle
The platform map makes more sense when it follows the contract lifecycle: research, offer, award, catalog, RFQ, modification, reporting, renewal.
A good platform page should explain who uses the system, when it appears, what data it touches, and what mistake to avoid.
FCP deserves both platform and pricing pages
The FAS Catalog Platform is a system, but the Product File and Services Plus File are pricing/catalog work products. That is why this library should cross-link FCP platform content with GSA pricing content.
Buyer-facing visibility is operational
GSA Advantage, eLibrary, and eBuy visibility depends on contract accuracy, catalog quality, and response habits. A Schedule contract is easier to sell from when the public-facing information is current.
What this looks like in practice
WorkflowOne contract, many systems
A contractor can submit an offer in eOffer, update the contract in eMod, manage catalog data through FCP, appear in GSA Advantage or eLibrary, respond to eBuy RFQs, and report sales through SRP. Confusing those systems creates avoidable stress.
Frequently asked questions
Should eOffer and eMod be one page or two?
Give the parent page a combined explanation, then split child pages. Offer submission and modification work are different contractor jobs.
Should FCP live under platforms or pricing?
Both, with different angles. FCP as a system belongs under platforms; Product File and Services Plus File belong under pricing/documents.
What platform pages should come first?
Start with eOffer, eMod, FAS Catalog Platform, eBuy, GSA Advantage, eLibrary, VSC, and SRP.