Retail and e-commerce: identity, orders, journeys, returns and risk
The retail module turns SellioCRM into the customer layer above your store: it reconnects anonymous browsing to the person who finally logs in, mirrors orders and inventory from your platform without ever pretending to own them, builds segments and journeys, runs coupons, recommendations, reviews, referrals and subscriptions, and treats a return as an offer rather than an obstacle. It is not an e-commerce platform: it never runs your checkout and never becomes the system of record for a sale. Optional and off until an admin turns it on.
The retail vertical is optional. While it is off, nothing in your CRM changes. An admin turns it on under Settings, in Verticals. It was built for e-commerce, physical stores and everything in between, and it starts from an uncomfortable fact: your CRM is not your store. It mirrors what the platform says, always carrying the source and the age of the data, and when it needs to act on the store it does so through a delegated action that is idempotent, subject to approval and recorded in a trail.
Most of your traffic is anonymous, and that is the real problem
Someone browses for two weeks, then buys. Without identity resolution those are two unrelated stories. The module links the behaviour that came before the login to the customer who appeared after it, and it is deliberately careful about how: a strong identifier such as the store customer id, a loyalty number or a social login can relink on its own, but an e-mail, a phone number or a device cannot. Families share a phone. Those go to human review instead of silently merging two people, and every merge can be undone.
Sync is where integrations quietly rot
Webhooks arrive twice, out of order, or not at all. Every record coming from the platform is keyed by source, resource, external id and version, so a duplicate or a late webhook is simply nothing. A nightly reconciliation compares counts against the platform, because the failure that hurts is not the error you see, it is the record that never arrived and that nobody noticed.
Orders, inventory and fulfilment are mirrored, not owned
An order carries the source system and the moment it was read, so you always know how fresh the figure is. The CRM does not invoice, does not capture payment for the store and does not decide stock. What it adds is what the store cannot see on its own: who this buyer is across every channel, what they did before buying and what happens next.
Behaviour at volume, without a screen ever reading raw events
Browsing generates far more rows than orders do. Events are stored in a table partitioned by month, and no screen queries it directly. What the interface reads are aggregates recomputed by a job, each stamped with the moment it was built. It is a deliberate trade: numbers are minutes old and always available, instead of live and occasionally taking the page down.
Segments, journeys and the limit on how often you may speak
Segments are built from behaviour, orders and profile, and feed journeys and campaigns. Above all of them sits a contact pressure rule: a cap per period, quiet hours, suppression lists and a priority between journeys, so that three campaigns cannot decide independently to contact the same person on the same evening. That engine was promoted into the shared core because capping and quiet hours are the same question in any industry.
Coupons, recommendations, reviews, referrals and subscriptions
Coupons carry rules and limits instead of living in a spreadsheet. Recommendations come from what people actually bought together. Review requests respect the state of the order. Referrals credit the person who brought the customer. Subscriptions track cycles and churn signals. None of it replaces your store: it is the relationship layer that the store never had.
Returns as an offer, not an obstacle
Eligibility is checked against the policy window from the order date. When a return is eligible, store credit can carry a bonus over the plain refund, so exchanging is genuinely more attractive than getting money back. That is modelled as an offer the customer can refuse, never as friction placed in the way of a refund they are entitled to.
Risk expressed as trust, not suspicion
Signals about an order or a customer add up into a trust score where one hundred means trustworthy and zero means high risk. Dismissed signals stop counting, which matters: a rule that keeps punishing a customer for something a human already cleared is a rule that trains your team to ignore the score.
Loyalty, your way
Loyalty works in two modes and you choose per tenant: a native append-only ledger with tiers, or a mirror of the external programme you already run. In the native mode a correction is a new entry, never an edit, so the balance can always be explained.
What this module does not do
- It is not an e-commerce platform: no storefront, no checkout, no payment capture for the store, and it is never the system of record for a sale.
- It does not decide stock; it mirrors what your platform reports, with the age of the data attached.
- It does not export to a data warehouse in this version; the path is documented but not built.
- It does not merge two people because they share an e-mail, a phone or a device.
- It does not show live event streams; the interface reads aggregates that carry the moment they were computed.