Use casesOperations & logistics
Turn free-text return reasons into a report you can act on
Codes free-text return reasons in any language into your fixed reason set, so per-SKU and per-carrier patterns show up in a weekly report.
- How it works
- Customers write return reasons in their own words and languages ('zu klein', 'not like photo', 'arrived broken, again'). The small model codes each one into your fixed set — sizing, damage in transit, wrong item shipped, quality, changed mind — and a weekly run aggregates by SKU and, where carrier data exists, by carrier. That is how you see which product's size chart misleads people and which route breaks parcels.
- Data you need
- A returns export with a free-text reason or comment field, plus order number and SKU. Return portals (Loop, ReturnGO and similar) and many Shopify setups have this; stock WooCommerce needs a returns plugin, and Shopify's native flow may only give a dropdown reason with an optional note — check your export first, because free text is where the value is. Per-carrier analysis also needs the carrier per order, often joined from a separate shipping export. You define the reason taxonomy: 8–15 codes works; 50 does not.
- What to expect
- Aggregate patterns come through even with some coding noise. Terse or sarcastic reasons ('great, thanks') get miscoded, multi-reason texts get one code unless you allow two, and if most customers pick a dropdown and leave the note blank there is little free text to work with. This is aggregate insight only — never use a single coded reason to deny an individual customer's refund.
- Where people stay involved
- Nobody checks individual codes, but a person owns interpreting the report — the model finds that a SKU has many 'too small' returns; deciding to fix the size chart is a human call. Spot-check a sample monthly to confirm coding quality.
Which model, and what it costs to run
Qwen3-32B
This job runs in bulk rather than to a waiting person, so size is not the constraint — we take the strongest independent score on structured output and tool calls that we may serve freely and that fits on a single card.
- Licence
- Apache-2.0
- Weights at 4-bit
- 18 GB
- Context
- 32K tokens
- Publisher
- Alibaba (Qwen Team)
What the hardware costs
One 48 GB card holds it
- Rent in the EU
- $1.60/hrScaleway, Paris (PAR2)
- Buy the card
- $7,569new, one-off
- Or rent it by the token
- $0.12 / $0.12per M in / out · Nebius AI Studio · EU
Hardware only, third-party prices from 2026-07. The figure excludes the KV cache, which grows with context length and how many people use it at once — sized properly in a conversation, not guessed here. Renting by the token is cheaper up front; why our customers still self-host is below.
Structured output and tool calls
Measured in a sandbox, on somebody else's functions. It tells you which models are capable of the shape of the job, not which one will survive contact with your API.
Independent measurement · UC Berkeley (Gorilla project) · board updated 2026-04-12
The API is cheaper per token. Here is why our customers don't use it.
We will not pretend otherwise: renting a model by the token from a serverless API costs less per million tokens than a card we run for you. We show that price on every use-case page. What it does not include is the part a shop with a customer database actually pays for.
- 01
Your data never leaves hardware you can point at
A serverless "we don't retain your data" is a clause in a contract. Running the model on a card in Amsterdam is a fact of architecture: your catalogue, tickets and customer records are never sent to a third party at all. For a GDPR audit, that is the difference between a promise and a floor plan.
- 02
The price cannot move without your say-so
A serverless rate card is somebody else's lever. The provider can raise the price, retire the model, or change the terms, and your cost moves with it. The same model on the same card costs the same next year — you own the number.
- 03
The model cannot be taken away
Hosted APIs deprecate models on their own schedule; the one you built on can be gone in a quarter. An open-weight model on your own hardware runs for as long as you keep the lights on. No vendor can end-of-life it out from under you.
And the price gap closes with volume: past a card you keep busy — very roughly four billion tokens a month — owning is cheaper outright, even before the three reasons above.
Getting a case like this one from a conversation to production takes about two months, and you can stop at the end of any phase.
Also in operations & logistics
All 13 →Sort supplier and carrier emails into the right queue
Tags every email to your purchasing or logistics inbox — delay, invoice, complaint — and routes it to the right queue, on your own infrastructure.
Pull order lines out of supplier PDFs and emails into a spreadsheet
Extracts SKU, quantity, price and delivery date from supplier PDFs and emails into rows you can import into your ERP or a spreadsheet.
Check supplier order confirmations against what you actually ordered
Compares each supplier confirmation against your purchase order and flags changed prices, quantities, substituted items and pushed delivery dates.
A morning digest of every delivery problem, in one email
One plain-language email each morning: the day's delayed, failed and held shipments, and the customers and orders behind each tracking number.
Next
Tell us what your team does by hand
Describe the process that takes the most time. We will say plainly whether a model is the right tool for it.