How to Evaluate a Beauty Retail System Vendor: 8 Scenarios to Test in a POC

For a beauty brand, the real test of a retail system is not how many boxes a vendor can tick on a feature list. It is whether the system can handle the operating details that appear every day at the counter: shade-level inventory, complex promotions and partial returns, samples and testers, batch and expiry management, beauty advisor (BA) follow-up, department-store transactions, online-to-store fulfillment, and distributor sell-through.

Most retail-system vendors can demonstrate POS checkout, member identification, inventory, promotions, ordering, and reporting. The differences usually become visible only when these capabilities are tested together in real beauty-retail scenarios.

A lipstick line may contain many shades. Full-size products, samples, gifts with purchase (GWP), and testers may require different inventory treatment. A partial return may affect the original discount allocation, loyalty points, coupons, GWP, and BA sales attribution. In China department stores, payment may be collected centrally by the department store while the brand POS still needs to retain transaction and reconciliation data. Distributor ordering also does not necessarily mean the product has sold through to the end consumer.

These scenarios often involve coordination across POS, CRM, inventory, WeChat applications, OMS, ERP, WMS, and B2B ordering systems. For a CIO or retail IT team, the POC should therefore verify more than whether a function exists. It should clarify whether the current version supports the scenario, what requires configuration or integration, how exceptions are handled, and whether transaction, inventory, member, payment, and channel data remain consistent.

Turn a Product Demo into an Acceptable POC

A beauty brand should prepare de-identified product, member, promotion, and channel data before the POC and require vendors to execute the workflow in an operable test environment rather than relying only on prerecorded demonstrations or prepared screenshots.

Suggested POC Test Data

Item Suggested Test Data
Stores Two test stores, including one configured as a department-store counter
Devices One store POS and one mobile device for a BA
Products Three lipstick shades in one line, two foundation shades in one line, and one full-size product bundle
Batches Two batch numbers for the same foundation SKU with different expiry dates, including one near-expiry batch
Product types Full-size products, samples, promotional GWP, and testers
Member One test member with points, a coupon, and historical purchase or trial records
Promotion One full-size purchase + threshold GWP + member coupon rule, with stacking, exclusion, and return rules defined in advance
Online order One buy-online-pick-up-in-store order from a WeChat mini program or OMS
Channel One distributor account with a dedicated price list, MOQ, case-pack rules, and applicable credit or payment-term rules

For every scenario, record the initial data, test steps, expected result, actual result, exception handling, and supporting evidence.

The vendor should also classify each requirement as:

  • Standard function
  • Configuration
  • Integration
  • Custom development
  • Not currently supported

This classification should later carry forward into SIT, UAT, project scope, and acceptance criteria.

Test Four Baseline Capabilities First

Before moving into beauty-specific scenarios, validate four basic retail capabilities that affect day-to-day store stability.

Baseline Capability What to Test Warning Signs
End-to-end transaction flow BA login, member identification, product entry, promotion calculation, split tender, receipt and transaction lookup Split tender requires separate orders; member, inventory and payment records cannot be linked after the transaction
Price override control and audit Unauthorized override is blocked, manager approval works, and the log identifies the user and terminal Shared privileged accounts; authorization codes cannot be traced to an individual
Offline operating boundary Vendor clearly explains what can be recorded offline, which benefits or payments are unavailable, and how data synchronizes after recovery “Offline sales” is presented as meaning every payment method and member benefit works offline
End-of-day reconciliation Payment totals can be traced back to transactions, including refunds, backdated entries and exceptions Only a sales total is available, with no payment breakdown or original transaction detail

If major gaps appear in these four areas, confirm the remediation approach and responsibility boundary before continuing with the industry POC.

The 8 Beauty Retail POC Scenarios

Scenario What It Should Validate
1. Shade-level sales and BA attribution Whether sales, receipts, inventory, member history and BA performance remain tied to the exact shade
2. Partial returns after complex promotions Whether GWP, coupons, points and refunds are reversed according to the original transaction rules
3. Full-size products, samples, GWP and testers Whether special inventory can be separated from sellable stock and its movement traced
4. Batch and expiry management Whether multiple batches of the same SKU remain traceable through receiving, sale, near-expiry alerts and returns
5. BA service and member follow-up Whether trials, preferences, recommendations and follow-up tasks become usable brand-owned customer records
6. Department-store counter sales and reconciliation How mall-collected payment, brand sales records, backdated entries and end-of-day reconciliation work together
7. Online order and store fulfillment Whether order dispatch, stock reservation, picking, collection and cancellation form a consistent workflow
8. Distributor ordering and retail sell-through Whether headquarters can distinguish orders, shipments, channel inventory and downstream retail sales

Scenario 1: Can Sales, Inventory and BA Attribution Reach the Exact Shade?

Why Test It

Customers buy a specific lipstick or foundation shade, not an abstract product family. If the shade exists only in the product name or a manual note, checkout may still work while inventory, promotions, member history, replenishment and BA performance remain recorded at the series level.

Headquarters may then see inventory remaining for the product line while the store has already sold out of its most popular shade.

How to Test It

Prepare three lipstick shades and two foundation shades from the same respective product lines, each with its own barcode and inventory. Include one shade in a promotion and exclude another.

Have the BA log in with an individual account, identify a test member, search or scan the exact shades, complete checkout, and record BA attribution according to the brand's normal rules.

After the sale, verify:

  • the receipt records the correct shade;
  • sellable inventory is deducted from the correct SKU;
  • member purchase history retains the specific SKU;
  • sales reporting uses the same product code;
  • BA sales attribution follows the agreed rule.

Then perform a partial return from the original transaction and check that inventory, revenue, member history and BA performance reverse consistently.

Pass Criteria

Every sellable shade should have a clear SKU, barcode, or equivalent product dimension. Product lookup, promotion, sale, return, inventory, member history and BA attribution should use the same underlying product identity.

If product master data comes from ERP, the POC should also clarify how product family, shade, barcode and listing status synchronize with the retail system and how interface failures are surfaced.

Warning Signs

Shade information exists only in free text; inventory reports stop at product-family level; a return restores inventory to the wrong SKU; BA performance cannot be traced to specific products; or the vendor repeatedly says it “supports variants” without showing sales, inventory and reporting together.

Scenario 2: What Happens When a Customer Partially Returns an Order with Multiple Promotions?

Why Test It

Beauty promotions rarely involve only one discount. A launch campaign may combine GWP, member coupons, points and bundle pricing.

Calculating the original checkout correctly is only half the test. The more revealing question is what happens several days later when the customer returns one item and the original order no longer qualifies for the same benefit.

How to Test It

Use a de-identified promotion rule supplied by the brand, such as:

  • purchase two specified full-size products;
  • qualify for a GWP after reaching a defined net-spend threshold;
  • allow one member coupon;
  • define in advance whether benefits stack or exclude one another;
  • define how coupons, points and GWP should behave after a partial return.

Complete the sale, inspect discount allocation, GWP lines, net payment, points and payment details, then retrieve the original transaction and return one item.

Verify whether the refund is based on the original allocated payment amount and how the GWP, coupon, points, inventory and BA attribution are adjusted.

Pass Criteria

Promotion priority, exclusion rules and discount allocation should be explainable and auditable. Normal returns should reference the original transaction, and store staff should not need to manually recalculate the refund.

Where brand-specific rules differ, the vendor should identify whether the requirement is handled through existing configuration, integration, or project-specific adaptation.

Warning Signs

The vendor demonstrates checkout but avoids returns; refunds require manual entry; gifts exist only as receipt notes rather than inventory items; discount allocation cannot be explained; or coupons, points, GWP inventory and BA performance remain unchanged after a return.

Scenario 3: Can Full-Size Products, Samples, GWP and Testers Be Managed Separately?

Why Test It

At a beauty counter, full-size products are sold, GWP is distributed with promotions, samples may be issued for member engagement, and testers are opened and retained at the counter.

All consume inventory or cost, but they should not automatically share the same sellable-stock definition.

How to Test It

Prepare a shipment containing full-size products, samples and promotional gifts. Receive them into the normal sales stock, promotional stock, tester stock, or equivalent logical inventory defined by the brand.

Then have an authorized BA:

  1. issue a GWP with a sales transaction;
  2. issue a sample according to the brand's member or campaign rules;
  3. move a full-size unit into tester inventory through the agreed approval process and open it for use.

If testers already exist as separate SKUs in the brand's master data, test the real master-data and receiving process rather than forcing a full-size-to-tester conversion.

Then simulate a consumed tester and a damaged inbound unit. Verify inventory movement and whether each record can be traced to store, product, quantity, user, time and reason.

Pass Criteria

Full-size products, samples, GWP and testers can be differentiated through separate SKUs, product attributes, logical inventory locations, or an equivalent model.

Only normal sellable stock should contribute to store available-to-sell inventory. GWP should be deducted through the relevant transaction or issuance process. Tester consumption, empty-container return or write-off should have a defined record.

If the brand wants to measure sample-to-full-size conversion, the POC should also establish whether the relationship is built in POS, CRM or the data platform.

Warning Signs

GWP appears only in receipt notes; sample issuance is maintained indefinitely in spreadsheets; testers share sellable inventory with full-size products; transfers into tester stock have no movement or approval record; or the vendor claims to measure sample conversion without explaining how issuance links to later member purchases.

Scenario 4: Can Batch and Expiry Data Follow the Product Through Receiving, Sale and Near-Expiry Handling?

Why Test It

The same foundation shade and SKU may exist in store under multiple production batches with different expiry dates.

Knowing that “10 units are in stock” is insufficient if the brand cannot identify how many belong to each batch, when each expires, and which units have entered the near-expiry period.

How to Test It

Prepare 10 units of the same foundation SKU:

  • Batch A: 4 units;
  • Batch B: 6 units;
  • different expiry dates;
  • Batch A already within the brand-defined near-expiry window;
  • one unit damaged in transit.

Receive the shipment and record the appropriate batch and expiry information. Handle the damaged unit using the standard return or discrepancy process confirmed for the project.

Then sell one unit and observe how the system selects or records the batch according to the brand's configured rule.

Finally, move the remaining near-expiry Batch A inventory to the appropriate non-sellable or handling location and initiate the relevant return process.

Pass Criteria

Receiving, sale, inventory transfer and return use consistent SKU, batch and expiry information. Expected quantities, actual receipts, damage discrepancies and return documents can be reconciled.

Where ERP, WMS and POS are involved, the project should clearly define which system creates batch information, which system deducts inventory, when data is written back, and how failures are compensated.

Warning Signs

Batch and expiry exist only in comments; receiving discrepancies cannot distinguish shortage from damage; near-expiry goods remain sellable after being moved into a handling status; or headquarters can see where a batch was initially shipped but cannot trace later sales, transfers and returns.

Scenario 5: Can a Beauty Advisor Follow Up After a Trial and Link the Later Purchase?

Why Test It

A customer may try two foundation shades and receive a sample without buying immediately. Several days later, the customer may return to store or place an online order.

The brand needs to know what the customer tried, what the BA recommended, whether a follow-up was scheduled, and how any later purchase is attributed according to the brand's rules.

If this information remains in a BA's personal WeChat account or on a paper consultation card, the brand's CRM may retain only the final transaction.

How to Test It

At the first visit, have the BA identify the test member and, within the brand's permitted data scope and member authorization, record relevant preferences, shades tried, recommended products and sample issuance.

Do not require every field to live in POS. Ask the vendor to explain what belongs in the retail system, CRM and WeCom-assisted clienteling tools.

Create a follow-up task for three days later with an assigned BA, planned date and topic.

At the follow-up date, have the BA open the task, record the interaction, and then simulate a repeat visit and purchase. Verify member history, task status and BA attribution.

Finally, transfer the original BA out of the test store and check how open tasks, customer ownership and permitted shared records are reassigned.

Pass Criteria

Member identification, preference or trial records, recommendations, sample issuance, follow-up tasks and later purchases should have a traceable relationship.

Task creation, reminders, execution and closure should follow a defined process. BA attribution should follow predefined brand rules. Customer access should remain role-based, and customer ownership or outstanding tasks should be transferable when a BA changes role or leaves.

If trial-record fields, attribution logic or WeCom data depend on project configuration, that dependency should be explicitly recorded in the POC result.

Warning Signs

The member profile contains only tier, points and transactions; trial information is stored only in unstructured notes; follow-up relies on each BA's personal calendar; POS, CRM and clienteling tools show inconsistent customer information; or customer relationships remain in personal accounts with no workable handover process.

Scenario 6: How Does a China Department-Store Counter Handle Mall-Collected Payments and End-of-Day Reconciliation?

Why Test It

This scenario requires additional context for international teams. In many China department stores, a customer may pay through the department store's central cashier or settlement system rather than directly to the beauty brand. The brand counter still needs to record the product, shade, member, promotion and BA attribution in its own retail system.

During major campaigns, a transaction may also be entered later based on the department-store receipt. At end of day, the brand needs to reconcile its own sales records against the amounts collected by the department store, including refunds and settlement differences.

The system therefore needs to distinguish three responsibilities:

  • who records the brand sale;
  • who actually collects the customer payment;
  • who performs financial settlement and reconciliation.

How to Test It

Configure one test location as a department-store counter.

Have the BA identify a member, add two specific shades, calculate the brand promotion, record BA attribution, and complete the transaction using a “mall-collected payment” method or the equivalent method actually used by the brand.

Verify that this payment type records the amount without initiating a second brand-side payment.

If the project stores the department-store receipt number or external transaction reference, test the agreed fields without presenting project-specific customization as a universal standard feature.

Next, simulate a transaction that was not entered during a peak promotion period. An authorized user should select the original business date and enter the relevant member, products, BA, amount and mall-collected payment information based on a de-identified department-store receipt.

The system should retain the actual entry timestamp, user and terminal.

For end-of-day reconciliation, compare:

  • brand sales detail;
  • mall-collected payment;
  • refunds;
  • the department store's daily settlement statement.

For commission deductions, concession settlement or invoicing differences, the vendor should explain whether responsibility sits with POS, the finance system or the department-store system and what reporting or interface data the POS can provide.

Pass Criteria

Brand sales and mall-collected payments can be reported separately without creating duplicate payment records.

Backdated transaction entry is permission-controlled, and both the business date and actual entry timestamp are retained.

End-of-day reconciliation can distinguish mall-collected payments, refunds and other payment types and drill back to the original transaction.

The retail system does not necessarily need to calculate every department-store commission or settlement rule itself. What matters is that transaction, payment, refund and settlement data have clear sources, interfaces and accountable owners.

Warning Signs

The vendor processes every department-store transaction like a normal direct-operated store payment; mall collection is recorded only as an undefined “other payment”; any cashier can change historical business dates; or POS sales are treated as the department store's final settlement amount without explaining commission deductions, refunds or discrepancies.

Scenario 7: What Happens When an Online Order Takes the Last Unit of a Popular Shade?

Why Test It

If an online customer buys the last available unit of a popular shade, the store needs to know that the inventory has been reserved. A BA should not then sell the same unit to a walk-in customer.

The store must receive the order, pick the correct shade, prepare it, notify the customer, complete pickup, and release the inventory correctly if the order is cancelled.

An order appearing in the back office proves only that the interface delivered the order. The POC should verify whether the store can actually fulfill it.

How to Test It

Set available inventory for a popular lipstick shade to one unit.

Have a test member place an order through the brand's WeChat mini program or OMS and select buy online, pick up in store (BOPIS).

After payment, verify:

  • the store receives a task or order notification;
  • total, reserved and available inventory are distinguishable;
  • the BA cannot sell the already-reserved unit according to the brand's rules.

The store associate then picks and prepares the correct shade, marks the order ready, and checks whether the status is returned to the upstream system and a pickup notification is triggered.

At pickup, validate the pickup code and confirm that it cannot be redeemed twice.

Repeat the test with an order cancelled after reservation but before pickup and record the exact point at which inventory becomes available again.

For third-party OMS orders, also test retry, alerting and reconciliation when status updates fail.

Pass Criteria

The order should have clear states from pending through preparation, ready for pickup and completed. Inventory should be reserved at the correct shade/SKU level, and total, reserved and available quantities should be distinguishable.

Cancellation, rejection or expiry should release inventory according to agreed rules, and the same order should not be counted twice in sales, inventory or member history.

If the brand requires more advanced picking or store-fulfillment functions, these should be confirmed separately as part of project scope.

Warning Signs

Online orders still rely on group-chat notifications; the store can see an order but cannot see whether the exact shade has been reserved; reserved inventory can still be sold in store; cancellation does not release inventory correctly; or recorded case videos are used instead of demonstrating the current product version.

Scenario 8: Can Headquarters Distinguish Distributor Orders from Actual Retail Sell-Through?

Why Test It

Shipping a new beauty product to a distributor only proves that inventory entered the channel. It does not prove that the product has sold to consumers.

If headquarters mixes distributor orders, shipments and downstream retail sales, channel performance can be misread. A region may appear to meet its target while distributor inventory is simply increasing, while a popular shade may already be out of stock at retail stores.

How to Test It

Configure one test distributor with:

  • permitted products;
  • a dedicated price list;
  • minimum order quantity;
  • case-pack multiple;
  • applicable credit-limit or payment-term rules.

Have the distributor order through the Pekon B2B Ordering Platform. First enter a quantity that violates the case-pack rule, then submit an order exceeding the applicable credit threshold and verify whether the rule and reason are clear.

After correction and approval, send the order to ERP and simulate a warehouse shortage for one shade so that ERP returns a partial-shipment or backorder status.

Then prepare de-identified sales and closing-inventory data for two downstream stores and feed those records into the agreed data flow through POS integration, API or file import, depending on the brand's planned model.

Headquarters should then compare:

  • ordered quantity;
  • approved quantity;
  • shipped quantity;
  • channel inventory;
  • downstream retail sales.

Test duplicate and missing data as well. Import the same day's data twice and omit one store to see how duplicates, missing submissions and definition differences are identified.

Retail sell-through does not appear automatically simply because a B2B platform exists. The project must define who supplies downstream sales data, how frequently it is returned, and who owns data quality.

Pass Criteria

Each distributor should see only the products, pricing and commercial policies applicable to it.

Order promotions, MOQ, case-pack multiples, credit limits or payment terms should be applied according to defined rules.

Approval, shortage, partial shipment and backorder should have clear states.

Headquarters reporting should distinguish distributor orders, shipments, channel inventory and downstream retail sales instead of treating “shipped to distributor” as “sold to consumer”.

The collection method, synchronization frequency, duplicate handling and missing-data process for sell-through data should be documented as part of project scope.

Warning Signs

The B2B platform merely moves manual ordering from WeChat into a web page; every distributor sees the same price list and policy; case-pack and credit rules still require manual checking; partial shipment in ERP appears as a fully completed order; or shipment volume is labelled as retail sell-through without a clear downstream data source.

What Should the CIO Receive at the End of the POC?

The result should not be only “Pass” or “Fail”. The purpose of the POC is to turn demonstrated capabilities and unresolved gaps into documented project boundaries that can later be carried into solution design, SIT, UAT and contractual acceptance.

At minimum, produce five deliverables:

  1. Capability boundary matrix
    Mark each requirement as standard function, configuration, integration, custom development or not currently supported.
  2. System and data responsibility matrix
    Define which system creates, maintains and writes back product, shade, batch, member, order, inventory, payment, channel pricing and sell-through data.
  3. Integration exception matrix
    Define synchronization timing, retry, duplicate handling, alerts, manual compensation and reconciliation ownership across OMS, ERP, WMS, CRM and B2B integrations.
  4. Sample-data validation results
    Use de-identified samples to validate members, points, coupons, shade-level SKUs, batch inventory, historical transactions, distributor policies and sell-through definitions.
  5. Go-live and service agreement
    Define pilot stores, department-store scenarios, rollout waves, training, issue severity, escalation, response mechanisms and release management.

For every requirement that needs development, separately confirm prerequisites, owner, deliverables, timeline, cost, upgrade compatibility and acceptance criteria.

A vague customization promise is often harder to manage later than a clearly documented product gap.

FAQ

Why not use a generic retail-system POC checklist?

A generic checklist can verify checkout, payment, returns and end-of-day reconciliation, but it rarely tests shade-level inventory, samples, testers, batch and expiry management, BA service, China department-store operations or channel sell-through.

Beauty brands should validate the basic retail transaction layer first and then use beauty-specific scenarios to test whether products, members, inventory and channels are modelled correctly.

Do all eight scenarios need to be completed by the POS alone?

No. A real retail architecture may involve POS, retail back office, CRM, WeChat applications, OMS, ERP, WMS and a B2B ordering platform.

The CIO should validate process continuity, data consistency, system-of-record responsibilities and exception handling rather than requiring every capability to sit inside one POS application.

What is the difference between a vendor demo and a POC?

A normal vendor demo typically uses data and workflows selected by the vendor to introduce the product.

A POC should use de-identified business rules and sample data supplied by the brand, with agreed steps, expected results and evidence that can be reviewed later.

The purpose is to verify capability boundaries and implementation conditions.

How should we distinguish standard functionality, configuration, integration and custom development?

A standard function should operate in the current product version. Configuration should be achievable through existing parameters or supported setup. Integration requires clearly defined upstream and downstream systems, data ownership and exception handling.

Custom development should have separately confirmed requirements, timeline, cost, upgrade compatibility and acceptance criteria. “Supported” on its own is not a sufficient POC conclusion.

Which teams should participate in the POC?

IT or the digital team should normally coordinate the POC, with participation from retail operations, CRM/member operations, merchandising, channel sales, e-commerce, finance and audit as relevant.

Department-store scenarios should include counter operations and finance. Online fulfillment should involve e-commerce or OMS teams. Distributor scenarios should include channel sales and supply chain.

If the brand already has ERP, OMS, WMS and CRM, does the retail system still need to be tested?

Yes. The more systems involved, the more important it becomes to validate how product, shade, member, order, inventory, payment and channel data move between them.

The project should define who creates, maintains and writes back each data type and who handles latency, failures, duplicate requests and data discrepancies.

From Feature Demonstration to Real Operating Validation

The value of a beauty retail system is visible in operational details: whether the correct shade is deducted, complex promotions and partial returns reconcile correctly, samples and testers remain traceable, batches and expiry dates remain manageable, BA service history can continue across visits, department-store transactions reconcile, online orders can be fulfilled without overselling, and channel inventory can be distinguished from actual retail sell-through.

For a CIO, testing these eight scenarios with realistic business data often reveals more about a vendor's product depth, integration capability and delivery boundaries than adding more rows to a feature checklist.

PEKON provides retail POS, CRM and loyalty, WeCom-assisted clienteling, WeChat mini-program capabilities, and the Pekon B2B Ordering Platform. These products can participate in the scenarios described above alongside a brand's existing ERP, OMS, WMS, CRM and finance systems.

Specific capabilities depend on the applicable product version, configuration, integrations, and agreed project scope. POC results should therefore clearly distinguish standard capabilities from configuration, integration and project-specific work.

For an overview of PEKON's beauty retail capabilities, see PEKON Beauty Retail Solution .

Related Content

Specific functions, implementation methods and integration boundaries should be confirmed according to the applicable product version, configuration, interface design and agreed project scope.