New Zealand AI Implementation Case Study: From WeChat Orders to SF Express Labels at a Cross-Border Health Retailer

How many times was one order copied?

On 24 July the client’s SF operator described her routine: ‘WeChat orders go into my master sheet, then I copy the content into the order template and import it into the SF system.’ One formula order passed through human hands five times between the WeChat group and the label.

What happened in a hundred days

Kickoff on 4 June with three data scenarios; a change of route at the end of July when marketplace APIs ran into copyright rules, toward SF Express ordering; SF API connected on 26 August; label callback live on 9 September; coaching mode from 10 September.

Month one: the smallest thing first

Phase one was three things: group message search, a China daily sales report, a store daily report. One loop in four weeks, with the client in a test group from week two. The first-month review on 9 July recorded an agreement that kept proving true: third-party interfaces are atomic capabilities, and ‘there is no such thing as “the interface exists, so it can be used directly”’.

Two hurdles: the WeChat account and marketplace APIs

For an agent to read WeChat groups, an account must stay logged in on an always-on machine. WeChat’s risk controls on remote and multi-device logins are strict; it took nearly a month of joint effort before the dedicated account was stable on 5 August. That experience is now item one on our kickoff checklist for every WeChat project.

The client wanted the agent on Taobao and WeChat Channels APIs directly. A week of research showed the platforms require a software copyright held by the store entity, which a locally deployed agent cannot obtain. On 28 July the route changed: daily sales stayed in ‘people report, the bot records’ mode, and development moved to SF Express ordering.

The journey of one order

First test-environment order on 28 August, first production order on 2 September. Only one node in the chain requires a person: check recipient, product, payment and ID, then tell the agent ‘review passed’. Without that sentence the agent does not call SF’s production API.

Why the label would not come

For a cross-border seller the label is the customer’s receipt; without it the order is not finished. SF Express generates the label only after the warehouse picks and packs and the outbound order is approved; before that the API returns nothing, even when the web page shows it. The final answer was a callback from SF: live in production on the evening of 9 September, with label paths written back to work orders once the 9 September callback was live.

A ‘false failure’

On the evening of 2 September an order’s quantity changed from 1 to 6; after cancel-and-rebuild the API reported ‘no stock’ and the work order was marked failed. The agent checked itself, found the rebuild had switched SKU, and queried SF: the order in fact existed with a waybill. Its conclusion went into the workflow rules: ‘Do not retry or create another order, to avoid shipping twice.’

A formula that was wrong for a month

On 30 July the client wanted the cost basis in the profit calculation changed from average to latest cost, and we changed the formula. The report went out at 21:00 every day, complete, with no step reporting an error, while the margin sat between 74% and 96% for a month. The client flagged it on 29 August; we fixed it on 1 September. The lesson is ours: a change to a core formula needs an ‘outside the normal range’ alert in the same commit.

Why does the bot ‘forget’?

The longer a conversation, the more likely early rules are dropped in automatic compression. ‘It did not forget. It can no longer see it.’ So rules go into skill files and Base tables, never only into chat. This diagram, sent to the client on 12 June, became our default explanation on every project.

The engagement: build one line in Q1, then coach

The first quarter is fully managed: we build, tune and integrate. Quarters two to four are coaching: we provide plans, answers and reviews, and the client’s team implements. The aim is for the client to grow its own AI capability. SF ordering was added to the first quarter after the client made clear that the step consuming staff hours had not yet been freed; that is what ‘build one line and build it through’ means. From 10 September, we coach.

Five lessons

Looking back, not one of the hardest parts was model capability.

• Preconditions before development: A compliant dedicated WeChat account, prepared a month ahead, at the top of the kickoff checklist.
• Judge compliance blockers early: A week of research and a change of road beats three weeks of drift.
• Creating an order and getting the document are two things: The label exists only after outbound; rely on the carrier’s callback, not our polling.
• A system error does not mean nothing happened: On any error, query by transaction number first, then decide whether to retry.
• Core formula changes need threshold alerts: Set the alert in the same change. That part is on us.

Where is it now?

On 11 September the daily work orders for WeChat ordering, verification, SF order creation, ID archiving and label return were running normally, and the client’s operator was asking for the next step: an order summary every hour or two with batch label download, and the dozen customer statements she updates daily. China daily sales and the store report go out at 21:00 every day, with margins back in the normal range.

Evidence boundary: numbers and quotations come from the project group chat and the meeting notes of 9 July and 1 September, each dated in the text. Daily sales figures for stores and channels are not given; SF transaction, order and waybill numbers, ID documents and recipient details were not used. The client is a New Zealand cross-border health-products retailer and is anonymised; company names, personal names, avatars and numbers in screenshots are cropped or pixelated; diagrams were drawn for this article.