General info
Currently, external partner SKUs (long IDs like LAVG6W574CT9K955) are imported but hidden on the product page, leaving customers without a clear reference. Internally, we already generate sequential SACLÀB SKUs (e.g. 6910) for tracking. To improve customer experience while still keeping external partner SKUs for operational flows, we need to introduce a dedicated field, retrofit existing drop-ship items, and update syncing logic.
User story
As a Creator on Saclab Airtable,
I want imported external SKUs to be stored separately from our internal SKUs,
So that customers always see a clean, short internal SKU on the product page, while external SKUs remain available for drop-ship partner sync, order flows, and communication.
Acceptance criteria
|
#
|
Scenario / Gherkin
|
Visuals / Notes
|
|
01
|
New field in Product Inventory
Given I am a Creator on Saclab Airtable bases
When I add or import a new bag via the Import table
Then the system should generate an internal SKU (sequential number, e.g. 6910)
And copy any provided SKU into a new field called ESKU (external SKU)
|
New Airtable field:
ESKU
Internal SKU uses existing rising number logic
|
|
02
|
Website visibility
Given a bag exists in Product Inventory with both an internal SKU and ESKU
When the bag is displayed on the product detail page
Then only the internal SKU is shown to customers
And ESKU (external) is never displayed
|
Example frontend: “SKU: 6910”
|
|
03
|
Retrofit existing drop-ship items
Given there are existing bags in Product Inventory with O/C = Drop-Ship and no internal SKU
When the system is updated
Then each of these bags should automatically receive a new internal SKU following the rising number logic
And the current partner’s SKU should be copied into ESKU
And if the bag already has an internal SKU, it must remain unchanged (no overwriting) And this process should run once at rollout across all live inventory
|
|
|
04
|
WooCommerce sync
Given a bag is synced to WooCommerce
When the SKUs are transferred
Then the internal SKU is synced as the WooCommerce product SKU
And the ESKU is stored as a WooCommerce but not visible on frontend but queryable via API/admin
|
Ensures both SKUs are available in WP, but only internal shown for customers
|
|
05
|
HubSpot + Slack sync
Given a bag is imported into the system
When it is synced to HubSpot
Then the internal SKU should be stored in the HubSpot deal for consistency with customer-facing SKU
And ESKU should also be synced into HubSpot as a separate property for reference in partner-related workflows
When a sale notification is posted to #bag-sales Slack
Then only the internal SKU is used in the message “Bag sold: DROP-SHIP [InternalSKU] [Bagname] Order ID: [OrderID] ([Status])”
|
Example HubSpot: Deal fields = {Internal SKU: 6910, ESKU: LAVG6W574CT9K955}
Example Slack: “Bag sold: DROP-SHIP – 6910 – Bag name”
|
|
06
|
Drop-ship sale flow
Given a bag has O/C = Drop-Ship
When the bag is sold
Then emails sent to the external partner must include the ESKU in subject and body
|
|
|
07
|
Removal scenario
Given: an email “Item Status Update” is received at sales@saclab.com with ESKU + bag name
When the ESKU matches a ESKU in the system
Then the bag should be moved to Removed by seller as per current logic
|
Uses ESKU for partner-triggered removals
|
