Litestore · Operator guide

Customers

Learn about customer accounts, saved addresses, lifetime spend, and the lifecycle stages derived from real order history.

Customer records, addresses, order history, wishlists, and lifetime spend all live in your own database.

A customer is the business identity. It exists whether or not the person ever signs in.

That is the distinction to hold on to: a customer is not an account. Someone who has bought from you twice as a guest and never made an account is still a customer, with a record, a history, and a lifetime spend.

Four records carry it:

Customer
CustomerAddress
Wishlist
CustomerInvitation

One customer per email address

Email uniqueness is case-insensitive and owned by a database index.

That is a duller sentence than it deserves, because it is the guarantee that keeps a person from becoming several people in your store.

Are Jane@example.com and jane@example.com the same customer?

Yes. The uniqueness is enforced regardless of case, so the two cannot both exist as separate records.

The alternative is the familiar mess: a customer with three records, spend split across all of them, an order history that looks thin, and a lifecycle stage that says "new" for someone on their fifth purchase.

Because the rule is held by the database rather than by whichever screen created the record, it applies to every path in — checkout, invitation, sign-in, and import alike.

Guest checkout still creates a customer

A guest checkout creates a customer record.

It is reconciled with the login account the first time that person signs in with the same email.

Nothing is lost in between. The guest orders were always attached to a real customer record, so signing in later attaches an account to a history that already existed rather than starting a new one.

Signing in

Customers and staff use the same login page and the same emailed sign-in link.

Email-and-password sign-in is not configured. There is:

  • No signup form
  • No password field
  • No reset flow

Google sign-in is available as a second option when you configure it.

What separates staff from customers is the role on the account, not a different login.

This removes a whole category of support work and a whole category of risk. Passwords you never store cannot be leaked, reused, or reset by someone who talked their way past your support team.

It also means "I can't log in" has one shape: the link did not arrive, or it went to a different address.

Invitations

Invite someone by email and they become an invited customer.

Signing in with that email accepts the invitation. There is nothing for them to click through, because the sign-in link is already the proof that they own the address.

Only one invitation can be pending at a time for a person, so re-inviting someone does not leave several live invitations behind.

What the customer sees

Signed-in customers get their own dashboard, covering:

  • Their overview
  • Their orders
  • Their discounts
  • Their reviews
  • Their settings

Addresses are edited under settings, and the wishlist has its own page.

Returns and refunds are requested from the individual order, not from a separate screen. That keeps the request attached to the thing it is about — the customer is looking at the order when they decide to send it back.

Lifetime spend

Spend and order count are updated when an order is paid, and reversed when one is cancelled.

Reversing on cancellation is the part that matters. A figure that only ever goes up is not a lifetime spend, it is a lifetime of attempts, and it would quietly overstate every customer who ever cancelled.

A standing alarm lists any customer whose stored totals disagree with what their paid orders actually add up to.

So the stored figure is not simply trusted. It is checked against the orders it claims to summarise, and any disagreement is surfaced as something to act on rather than left to be discovered.

Lifecycle stages

Each customer sits at exactly one stage:

new
invited
registered
purchased
repeat
restricted
banned

The stage is worked out from order count, account state, and any live invitation.

It is not a tag applied by hand. Nobody has to remember to move someone from purchased to repeat, and nobody can accidentally mark a customer as repeat who has bought once.

Email broadcasts target those stages, which is what makes them worth trusting. A campaign aimed at repeat customers reaches people the order history says are repeat customers.

Three groups are excluded from broadcasts:

  • Restricted customers
  • Banned customers
  • Unsubscribed customers

The account score

The customer page shows:

  • Churn risk
  • Likelihood to buy again
  • Predicted lifetime value

These are calculated from that customer's ordering cadence each time you open the page.

Nothing is stored, so it is never stale. There is no nightly job to fall behind, and no cached score describing a customer as they were last month.

The score is read-only. It is a reading of the order history, not a field you can set.

How a customer record accumulates

  1. Someone checks out, with or without an account, and a customer record is created or matched by email.
  2. That record accumulates orders, addresses, and lifetime spend, and its lifecycle stage is re-derived whenever an order is paid, cancelled, or refunded.
  3. They serve themselves from the dashboard while you segment email on stages that came from real orders.

Where to look

Look at the customer record for anything about the person: their history, their addresses, their spend, their score, and their conversations with you.

Look at the order for anything about a single purchase, including the returns and refunds on it.

Use lifecycle stages rather than manual tags when segmenting email, because the stages are derived from what people actually did.

Treat the drift alarm as a signal that a stored total needs investigating, not as noise to clear.

The principle underneath the whole model:

The customer is the identity, the login is only a way of proving you are it.

On this page