Product
What the platform does
Three arms over one shared database and one tenant identity. Each is described here as it is built, not as it is planned.
Content
A headless content layer that stores what, never how.
Content is structured, not a pile of pages. A business defines its own content types and field sets — the fields a wine has, the fields a care guide has — and every entry is checked against that definition before it is published. Validation happens once, at the publish boundary, so anything the API serves has already been checked.
Entries are localised per locale, versioned, and restorable to any earlier saved state. Assets carry generated renditions. Navigations and redirects are content a person edits, not server configuration a developer deploys. Releases group changes so a set of entries goes live together, on a schedule when that is what the business needs.
Nothing in this arm renders a website. It serves content over an API to whatever does the rendering — a site, an application, a printed catalogue, a script read aloud.
Commerce
A B2B-first engine in which retail is the constrained case.
Commerce models the hard cases first, so the simple ones fall out of them rather than needing a second system. Companies have their own locations and contacts, and an assignment can be made at either level. Orders carry lines. Payments are allocated against invoices rather than assumed to cover them. Invoices and credit notes share one numbering sequence that never leaves a gap, and carry real payment terms.
Stock is an append-only log of movements across warehouses. On-hand and allocated quantities are derived from that log rather than kept as a running total, so the figures can be rebuilt from first principles and reconciled against what actually happened.
Retail is the same model with the company account, the terms and the credit control left off — a constrained profile, not a second implementation. And committed business effects are reversed, never erased: a correction writes a new record, and the original stays legible.
Social messaging
Inbound conversations, drafted by AI, sent by a person, inside the platform's own windows.
Social messaging brings a business's inbound conversations from Instagram, Facebook and WhatsApp into one reviewed inbox. A conversation begins when a customer messages the business. Each inbound message is read against context assembled from that business's own catalogue, policies and published content, and an AI draft reply is prepared together with a confidence assessment and the sources it drew on. A person reads, edits and sends every reply.
How it behaves
- Reactive and inbound-only
- A conversation is started by the customer, never by Atelye. There is no cold outreach, no broadcast and no bulk messaging.
- Inside the granted window
- A reply is sent only inside the messaging window the platform grants for that conversation. Window state is tracked per conversation and enforced by the channel adapter, not left to anyone's judgement.
- Reviewed before it is sent
- No message leaves the platform without a person approving it. AI output is a draft, and the difference between the draft and what was actually sent is recorded.
- Disclosed, with a way out
- AI involvement is disclosed to the customer and a route to a person is always available. A business can change the wording and the language of the disclosure; it cannot switch the disclosure off.
- Not a publisher
- Atelye does not compose posts, schedule content, run campaigns or send marketing messages, and it asks the platforms for no permission that would let it.
- Explainable afterwards
- A customer is held as a channel-scoped opaque identifier and is not stitched into a cross-channel profile. Every draft records the model, the context it was given and the confidence it produced, so any reply can be explained after the fact.
Enquiries
Atelye is not sold from this site, and there is nothing here to sign up for. To ask about the platform, write to the operator.