A shared customer context layer
Customer Management is the system that turns raw orders and interactions into a clearer profile of who the customer is, what they bought, and how the business should respond next.
Customer Management is the system that turns raw orders and interactions into a clearer profile of who the customer is, what they bought, and how the business should respond next.
Retention, support, and campaign work get much harder when order history, account state, segmentation, and messaging signals all live in separate silos.
Once customer context is more structured, teams can build better segmentation, lifecycle messaging, and app experiences without manually merging data every time. Customer logins live on their own dedicated, customer-facing surface — kept separate from the merchant dashboard on purpose, so a shopper's account and a merchant's account are never mixed up.
A list of completed purchases does not tell a support team what the customer recently tried to do, what segment they belong to, or why a campaign underperformed.
Support, marketing, and product teams need to see enough of the same customer context that their actions do not conflict with each other.
Both Boron and Krypton are building toward full self-serve customer accounts — login, saved addresses, order history — on the same foundation that already powers products and carts. This is real, active work, not a someday idea.
Customer Management brings identity, order history, and recent commerce behavior closer together on the operator side.
Merchant impact: Operators can understand a customer faster without checking several tools.
Developer impact: Downstream workflows can start from one customer context object instead of patching partial records together.
Example: A support agent sees the customer's last order, cart intent, and recent account activity before responding to a complaint.
Customer context is more useful when it can be turned into lifecycle segments and growth actions cleanly, built from the same canonical event vocabulary Analytics uses.
Merchant impact: Brands can target more relevant campaigns and retention work.
Developer impact: Segment logic can be built from clearer platform events and profile fields instead of ad hoc exports.
Example: A team identifies high-AOV repeat customers separately from one-time discount-driven shoppers.
Support quality improves when account, order, and storefront behavior are not scattered.
Merchant impact: Teams respond faster and with more context.
Developer impact: Account and support surfaces can consume shared data instead of assembling custom data-fetch pipelines ad hoc.
Example: A support operator can tell whether a refund request follows a failed delivery, a duplicate order, or a mistaken purchase.
Customers get their own dedicated login and account area, kept separate from the merchant dashboard. Full self-serve account features are being built out on that same foundation.
Merchant impact: Teams evaluating Prebit for a customer-account-heavy use case (loyalty, saved addresses, self-serve order tracking) get a clear picture of what's live today and what's rolling out next.
Developer impact: `accounts-storefront` (`accounts.prebit.store`) is the dedicated customer-facing account/login surface, distinct from `prebit-centralised-login` (merchant/seller login). The implementation path for a full `useCustomer()` is already mapped in the framework's own folder layout, so it's additive on top of what's already there.
Example: A merchant runs on order confirmation emails and support-driven order lookups today, with a self-serve "my orders" customer login experience rolling out on the same track.
Every layer feeds the next: Customer Management sits inside this chain rather than bypassing Commerce Engine's data contracts.
Profile state starts with customer and account records; `accounts-storefront` is the dedicated customer-facing login/account app, kept separate from merchant/seller login (`prebit-centralised-login`) on purpose.
Order history, checkout behavior, and lifecycle events add depth to the profile, drawn from the same canonical event envelope Analytics and Marketing Hub use.
Support, growth, and messaging systems can consume the customer context for downstream actions.
The resulting profile view helps teams make better support and retention decisions day to day.
Operators can answer customer issues with more context and less back-and-forth.
Segmentation and lifecycle work become more grounded in actual customer behavior.
Customer-facing experiences can reflect richer profile truth over time as account features mature.
Teams spend less time jumping between order, account, and messaging tools to understand the same customer.
Lifecycle systems, account surfaces, and segmentation logic can build on cleaner profile data.
Storefront, support, and automation workflows can draw from the same customer picture more easily.
`useCustomer()`'s rollout is explicitly mapped in both Boron and Krypton's folder layout, so a developer building on the framework always knows exactly where account logic plugs in.
Customer actions and order state can feed retention logic more naturally when the model is explicit.
A customer contacts support after a failed delivery and the agent needs order plus account context instantly.
Outcome: Faster, more accurate resolution.
A retention team segments customers by product interest and repeat behavior before running a lifecycle campaign.
Outcome: More relevant messaging and better repeat-purchase quality.
An agency standardizes customer segmentation and support workflows across multiple stores.
Outcome: Cleaner retention systems with fewer disconnected apps.
Developers plan a `useCustomer()` implementation for a client that specifically needs self-serve account features, scoping it against the documented rollout path.
Outcome: Accurate, confident scoping from day one.
Operators can move faster when the platform assembles the customer context for them.
A shared profile reduces wasted time hunting through several systems before taking action.
Workflows perform better when they start from customer truth rather than partial lists and exports.
A stronger customer model keeps later self-serve account surface work from becoming progressively messier.
Good customer management helps returning visitors and account users find what they need with less friction.
Richer customer context can inform what the storefront or account layer emphasizes to different audiences.
Search and paid visitors are more valuable when the business can follow up intelligently after the first order.
Consistent customer and order context helps the wider platform keep support, retention, and conversion experiences coherent.
A direct, factual read on where each platform is strong, and where Prebit takes a different approach.
Directional and factual. Validate against your own catalog complexity, channel strategy, and budget before deciding.
Plain answers to what merchants, agencies, and developers actually ask.
Start free. No credit card required. Explore the rest of the Prebit platform once you're in.