What does a Product Catalog FTE own?
A Product Catalog FTE on ftes.ai owns the product catalog of an online store as a whole job function: the titles, attributes, descriptions, images' alt text, structured data and Shopping-feed fields of every SKU, and the collection pages that group them. It is accountable for one outcome, every SKU page complete, found and approved, and it is reviewed on targets the store owner sets, such as completeness on the top two hundred SKUs by revenue or disapprovals cleared within two days.
It does not own pricing, product selection or brand positioning. Those stay with the store owner. The Product Catalog FTE makes the pages that carry those decisions complete and accurate, and it does so inside Shopify, WooCommerce, BigCommerce or Adobe Commerce rather than in a separate tool the store then has to sync.
How does the catalog audit work?
The catalog audit is the first thing the Product Catalog FTE does and the evidence base for everything after. It reads every SKU and scores it on completeness of title, attributes, description, images and schema; on duplication against sibling SKUs; and on feed health from Merchant Center. It then ranks the gaps by the revenue at stake, using the store's own sales data, so the first rewrites land on the pages that matter most.
The audit is a report in the Catalog tab, not a to-do list dumped on the owner. Each finding names the SKU, the missing or duplicated field, and the estimated revenue exposure with the arithmetic shown. The owner can accept the proposed order of work, change it, or exclude collections the Product Catalog FTE must not touch.
Where does a rewrite get its facts?
A rewrite by the Product Catalog FTE may only use three sources: fields already in the catalog, a supplier sheet or specification the store uploaded, and copy the store owner approved before. Every claim in a proposed title or description is mapped back to one of those sources, and the mapping is shown beside the draft in Approvals. A fibre content, a weight, a dimension or a compatibility claim that appears in none of them is not written; it is flagged as a gap for the owner to fill.
This fact-gate is the mechanism that separates a Digital FTE from a text generator. A generator fills gaps with plausible words; the Product Catalog FTE refuses to. The refusal is visible in the workspace as a flagged field, which is the honest state of a catalog with missing data.
How are Shopping-feed disapprovals handled?
Google Merchant Center disapprovals and warnings are checked by the Product Catalog FTE every day. When an item is disapproved, the FTE reads the reason Merchant Center gives, names the failing field, such as a missing GTIN, a price mismatch between feed and page, or an image that breaks a policy, and drafts the fix at the source: in the product record, not in a feed rule that papers over it.
The fix is then re-checked against the same rule before it is proposed, so the owner approves a change that already passes rather than one that might. Disapprovals the FTE cannot fix from available data, such as a GTIN only the supplier holds, are surfaced as requests to the owner with the exact field and the SKU named.
What waits for approval and what does not?
The Product Catalog FTE starts at Level 0 on the autonomy ladder: every rewrite, attribute change, alt-text addition and schema change is a proposal in Approvals with a before-and-after view and its evidence. Nothing changes on the live store until the owner approves it. Bulk work is proposed as a batch the owner can review in one sitting, with the same evidence per SKU.
Once the approval record shows a class of change is routinely accepted, for example alt-text additions or schema completion, the owner can promote that class to run without a gate. Copy rewrites usually stay gated longer because voice is a judgment. Any promotion can be taken back at any time, and every change stays logged either way.
What does it report, and how honestly?
The Product Catalog FTE reports four things it can measure: catalog completeness by collection, open and closed disapprovals, rewrites live, and the search movement of rewritten pages from Google Search Console. Search movement is reported per page against the date the rewrite went live, with the caveat that ranking changes have many causes and the FTE names the ones it can see.
It does not report conversion lift from a rewrite unless the store runs a controlled test, because a before-and-after comparison on a live store is not evidence of cause. If the store also employs a Conversion FTE, that role tests the rewritten pages properly and reports the result at full sample size.
Which tools does it work in?
The Product Catalog FTE works inside the store platform, currently Shopify, WooCommerce, BigCommerce and Adobe Commerce, with the permissions the owner grants per organization and per property. It reads Google Merchant Center for feed health and Google Search Console for search movement. Its work is reviewed in the ftes.ai workspace, and the credentials it uses are encrypted at rest and revocable at any time.
It does not require a separate PIM, a spreadsheet export, or a migration. The store's catalog stays where it is; the FTE proposes changes to it. Stores that already run a PIM can point the FTE at it as the source of truth for attributes.