A florist arranging red tulips and amaryllis outside a shop with a striped awning and string lights
B2C

The hard part comes after the sale.

The return that nobody owned. The marketing that went to someone who had already asked you to stop. Cyril starts a retail business in B2C mode, with a pipeline that runs past the checkout and consent handled once rather than per tool.

A pipeline that runs past the checkout.

Six stages covering the whole lifecycle, not just the sale. Retail is contact-centric, so the record is a person, not an account.

New enquiry
Product interest
Checkout / OrderCommerce stage, optional
FulfilmentCommerce stage, optional
Completed
Returned / CancelledWhere a follow-up task is raised

Service-led rather than product-led? The commerce stages come out at onboarding. That removal is part of the process, not an exception to it.

One customer, everything after the sale.

Sales runs in B2C mode, with individuals and deals rather than companies and stakeholders. Deals, tickets, invoices and campaign engagement all sit on the same person.

  • Sales, B2C modeThe person is the record, from enquiry to return.
  • SupportThe return and the questions that follow it.
  • FinanceInvoices and payments on the same customer.
  • MarketingCampaigns sent to the same contacts, not a copy of them.

Consent and suppression, handled once.

One suppression list, read by campaigns rather than copied into them, with one-click unsubscribe and STOP handling. A single list is the thing a multi-tool stack most reliably gets wrong, so it is raised for every retail business.

Two automations we suggest.

Aimed at the transitions customers actually notice. Like every automation, each can be run in test mode against a sample record before you rely on it.

  1. Raise a follow-up task when a deal moves to Returned / Cancelled.
  2. Notify the owner when a customer’s lifecycle stage changes.

Four rules we raise.

Each is raised for you to decide. Returns and refunds aren’t tracked in Cyril yet, so those two are notes for your own process; consent and suppression are handled in the product.

  1. A returns window.
  2. A refund approval threshold.
  3. How consent is captured, and where it is read from.
  4. A review of who is suppressed, and why.

Where this shape does not fit.

These defaults assume a contact-centric business whose difficult moments come after the sale. High-volume transactional retail with no real relationship to manage gets more from a dedicated commerce stack.

  • Inventory management, warehousing and shipping-carrier integration are not part of this.
  • Very high order volumes are better served by a commerce platform with Cyril alongside it.
  • Point-of-sale hardware and in-store operations are outside what these defaults cover.

Common questions

Does this replace our commerce platform?

No. Inventory, warehousing, carriers and point-of-sale are outside this. If you run high order volumes, the better shape is a commerce platform for the transaction and Cyril for the relationship, the returns and the marketing around it.

How is consent actually handled?

One suppression list, read by campaigns rather than copied into them, with one-click unsubscribe and STOP handling. A single list is the thing a multi-tool stack most reliably gets wrong, which is why it is raised for every retail business.

What happens to a return that nobody picks up?

Raising a follow-up task when a deal moves to Returned / Cancelled is one of the two automations we suggest for retail, because the return nobody owns is what customers notice. Like every default it is a suggestion, and you can run it in test mode first.

Is this an industry template?

No. They are defaults raised as proposals at onboarding, each with its reasoning, which you add, change or skip. The commerce stages in particular come out often, and that removal is part of the process.

Own what happens after the sale.

Founding members lock in today’s price and get priority onboarding.