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) |
New Airtable field: 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 |
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 |
Leave a Reply
You must be logged in to post a comment.