B2B, B2C and dealer-portal commerce on one data model
Enterprise e-commerce development starts with product data, not with a storefront. B2B trade needs customer-specific pricing, account balances, order approval and dealer hierarchies. We feed the same catalogue to the B2C storefront, the dealer portal and the ERP from a single data model, and deliver against written acceptance criteria.
SCOPE SUMMARY
Who owns product data, schema and page speed?
Three items go unassigned in most e-commerce contracts: the product attribute data model, the validity of Product and Offer schema, and the performance threshold for the product page and the cart. Marketing looks at campaigns, engineering looks at features, and these three fall between them. We write all three into the contract as measurable acceptance criteria.
| Responsibility | Marketing agency | Software agency | Baki Bilisim |
|---|---|---|---|
| Who defines the product attribute data model and the mandatory field list? | —Out of scope | ~Partly, on separate request | ✓In scope |
| Who commits to Product and Offer schema staying valid after a catalogue update? | ~Partly, the recommendation only | —Out of scope | ✓In scope |
| Who writes the performance threshold for the product page and the cart? | —Out of scope | ~Partly, on separate request | ✓In scope |
These are written as categories and name no competitor. Why the split between building and visibility is a way of working rather than a positioning line is set out in the detailed account of the two-agency problem.
Where does B2B e-commerce diverge from a B2C store?
In B2B e-commerce the price changes per customer; in B2C it is the same for everyone. Contract price lists, discount tiers, account balances, credit limits, minimum order quantities, an order approval step and a main-dealer to sub-dealer hierarchy are specific to B2B. These rules belong in the data model, not in the interface.
The loss usually starts in one particular way. The project is built as a B2C store; six months later the dealers want to order through the same system. Because the price is held as a single value on the product record, no customer group can be added: discounts move into the campaign module and account tracking moves into a spreadsheet. From that point every new rule makes the cart logic heavier, and the catalogue is eventually rebuilt.
| Decision point | B2C store | B2B trade and dealer portal |
|---|---|---|
| Price | One public list for everyone | List bound to customer group and contract, with discount tiers |
| Order flow | Basket, payment and confirmation in one step | Quotation, approval chain, partial shipment, repeat order |
| Collection | Instant card payment | Account balance, credit limit, payment terms and reconciliation |
| Catalogue visibility | The whole catalogue is public | Product, price and stock visibility varies by dealer group |
| Order quantity | Any quantity | Minimum order, case or pallet multiples, unit conversion |
| Account structure | A single user | Main dealer, sub-dealer, purchasing and approver roles |
The second loss is speed. A corporate buyer often opens the catalogue from the field, on a weak mobile network. When the product listing loads late, the supplier evaluation ends inside the search results. LCP, or Largest Contentful Paint, is the time until the largest content element on the page becomes visible, and Google publishes a public threshold for it.
2.5 s
The LCP threshold Google treats as “good”. Product listing and product detail pages are the first page types to breach it as a catalogue grows, because each row carries an image, a price and an availability state.
Source: Google web.dev — Largest Contentful Paint (opens in a new tab) · Accessed: 2026-07-29
The third loss is invisible until someone looks for it: product data quality. A missing brand, unit of measure or availability field does not break the page, so nobody reports it. It breaks the on-site filter, the search engine's classification of the product and the Product structured data at the same time.
What is delivered in an enterprise e-commerce development engagement?
Nine deliverables make up the engagement: scenario and data model map, platform decision table, product data dictionary, category and URL architecture, ERP mapping, dealer portal flow, multi-language and currency structure, Product schema, and the performance budget with handover. Each one carries its format and its delivery week in the contract.
01 · SOURCE
ERP and accounting
Stock, price lists, discount tiers, account balances and order status are produced in one place. The site reads those values; it never keeps a second copy of them.
02 · CORE
One product data model
Product, variant, attribute, customer group and price list relationships are defined here. A rule is written once, and every surface uses the same source for it.
03 · SURFACES
Storefront, portal, app, schema
The B2C storefront, the signed-in dealer portal, the field team's mobile application and the Product schema sent to search engines are fed by the same data.
| # | Deliverable | Format | When |
|---|---|---|---|
| 01 | Scenario and product data model map | Decision document + flow diagram mapping B2C, B2B and dealer roles onto one catalogue | Weeks 1–2 |
| 02 | Platform decision table | Off-the-shelf, headless and custom build compared on business rules, scale, team and maintenance cost | Week 2 |
| 03 | Product data dictionary and attribute matrix | Field list per product type + mandatory/optional matrix + image and document rules | Weeks 2–4 |
| 04 | Category, filter and URL architecture | Category tree + indexable filter rules + canonical and pagination policy | Weeks 3–5 |
| 05 | ERP and accounting integration mapping | Two-way field mapping table + refresh frequency + failure scenarios + reconciliation log | Weeks 4–7 |
| 06 | Dealer portal permissions and order approval flow | Flow diagram + role matrix covering dealer group, price list, credit limit and approval chain | Weeks 5–9 |
| 07 | Multi-currency, multi-language and hreflang structure | Structure decision (per-market price list or reference rate) + reciprocal hreflang matrix | Weeks 6–10 |
| 08 | Product, Offer and BreadcrumbList schema | JSON-LD schema files + validation report + regression check for catalogue updates | Weeks 9–12 |
| 09 | Performance budget, measurement and handover | Budget file for listing and cart + measurement setup + team training + source code transfer | Weeks 12–16 |
If a new corporate site is on the agenda at the same time, the information architecture and design system are shared with the corporate website project rather than produced twice.
In which six phases does the build proceed?
The build runs in six phases: inventory, data model and platform decision, catalogue preparation, integration, hardening, then release and handover. Each phase has a written deliverable, a verifiable acceptance criterion and a named accountable party. Product data comes from your team; the templates, the measurement and the validation come from us.
-
01
Inventory and scenario definition
The existing catalogue, ERP fields, pricing rules, customer groups and order flow are pulled into one inventory. Which scenario opens in the first release and which one waits for a second phase is written down before any build decision is made.
-
02
Data model and platform decision
Product, variant, attribute, customer group, price list and account relationships are modelled. The platform decision is then made against that model, with a comparison table and the reasoning behind every row rather than a preference.
-
03
Catalogue and product data preparation
The mandatory attribute list is agreed, the current data is measured against it and the gaps are filled. Image, unit of measure, brand, GTIN and technical document fields are completed before migration, not after go-live.
-
04
Integration and flow setup
ERP and accounting field mapping, payment and shipping connections, order approval and return flows are built. What happens when a connected system does not respond is written before the connection is opened, not discovered in production.
-
05
Performance, schema and accessibility hardening
The performance budget is applied to the product listing and the cart, Product, Offer and BreadcrumbList schema are written and validated, and the keyboard and screen reader flow through search, filtering and checkout is audited.
-
06
Release, measurement and handover
The release checklist, the redirect map for old product and category URLs, the measurement setup, team training and the source code transfer are completed. The code, the catalogue data and the platform accounts belong to you.
The phase structure is common to every engagement; the full version is on the six-phase working model page.
Against which acceptance criteria is the system delivered?
An acceptance criterion is a threshold anyone can verify independently after handover. For e-commerce we write six: product page LCP, cart and checkout INP, layout shift on the product listing, mandatory attribute completeness, Product and Offer schema error count, and the indexing rate of category and product URLs.
| Criterion | Threshold | Measurement tool |
|---|---|---|
| Product detail page LCP (mobile) | < 1.8 s | Lighthouse lab measurement + CrUX field data |
| Cart and checkout step INP | < 200 ms | CrUX field data + interaction tracking |
| Layout shift on the product listing (CLS) | < 0.05 | Lighthouse + CrUX |
| Mandatory attribute completeness | ≥ 98% | Field audit run on the catalogue export |
| Product and Offer schema errors | 0 | Schema Markup Validator + Rich Results Test |
| Indexing rate of category and product URLs | ≥ 95% | Search Console page indexing report |
INP, or Interaction to Next Paint, is the delay between a click and the screen updating in response. Adding to the basket, changing a quantity and moving between checkout steps are the most repeated interactions in commerce, so the interaction budget is written around those three rather than around the home page.
200 ms
The INP threshold Google treats as “good”. Interactions in the cart and checkout steps have to stay inside this budget, on the device the buyer actually uses.
Source: Google web.dev — Interaction to Next Paint (opens in a new tab) · Accessed: 2026-07-29
One item is deliberately missing from the list: conversion rate. We give no revenue or conversion commitment, because those figures form together with your product, price, stock and sales decisions. What we commit to are the technical thresholds inside our control. The same rule applies to us: our own measured scores are published with their measurement dates.
In which industries does enterprise e-commerce development pay off?
It pays off most in dealer network, spare part and export scenarios. The common pattern is a wide catalogue, a price that varies by customer and an order that passes through an approval chain. In the five sectors below the build starts from the same product data model; what changes is the surface layer on top of it.
- 01 Manufacturing and factories Spare part and consumable sales need search by part number, attached datasheets and a compatibility table before they need a checkout.
- 02 Retail chains When store stock, the online catalogue and campaign rules are not held in one source, price and availability inconsistencies reach the customer.
- 03 Franchise and dealer networks Dealer-specific pricing, credit limits and the order approval chain are the core of a dealer portal, fed by the same dealer record as the location pages.
- 04 Export industry Multilingual catalogues, currency and delivery term differences: an overseas buyer wants to see what the price covers on the product page itself.
- 05 Corporate holdings Several subsidiaries with separate catalogues: a shared data model and shared governance remove the development work that would otherwise be repeated per company.
Most asked questions about enterprise e-commerce
How does B2B e-commerce differ from B2C?
In B2B e-commerce the price changes per customer; in B2C the price is the same for everyone. Contract-bound price lists, discount tiers, account balances and credit limits, minimum order quantities, an order approval step and a main-dealer to sub-dealer hierarchy are specific to B2B.
These rules are defined in the data model rather than in the interface, and adding them later usually means rebuilding the catalogue.
How is ERP integration set up?
ERP integration starts with a field mapping table: which field is produced in which system, in which direction it flows and how often it is refreshed. Stock, price lists and account balances usually flow from the ERP to the site, while orders, customer records and return requests flow from the site to the ERP.
The critical part is the failure scenarios: how stock is displayed when the ERP does not respond, how duplicate orders are prevented and how the reconciliation log is kept. Integration is a monitored service, not a one-off task.
Should we choose an off-the-shelf platform or a custom build?
The decision rests on three questions: are your business rules standard, what is the scale of your catalogue and traffic, and which team will maintain the system. In a standard B2C scenario an off-the-shelf platform is both faster and cheaper.
Where there is customer-specific pricing, a multi-tier dealer hierarchy or a tight ERP dependency, an off-the-shelf platform turns into a stack of plugins, and at that point a headless architecture or a custom build becomes more predictable. We give the decision in writing, as a comparison table with the reasoning behind each row.
How are dealer-specific prices and account balances managed?
Dealer-specific pricing is managed through price lists bound to a customer group and a contract identifier; a single price is never stored on the product record. A signed-in dealer sees only their own list, discount tier and campaign rules.
Account balance, credit limit and overdue debt are read from the ERP, and when a limit is exceeded the order is not silently rejected but routed to an approval step. Prices and balances are shown only to the signed-in user and are never exposed to search engines.
Which currency and language structure suits exporters?
In export commerce language and currency are two separate decisions. Each language needs its own URL and reciprocal hreflang tags; if the content is swapped dynamically at the same address, the page is indexed in one language only.
For currency, either a separate price list per market or a single reference currency with a maintained exchange rate is used. The product page must state which delivery terms (Incoterms) and tax treatment the displayed price includes, and the priceCurrency value in Product schema has to match the price shown on screen. The sector detail sits on the export industry page.
What happens if product data is incomplete?
Incomplete product data turns into loss in three places: on-site filters return the wrong results, search engines cannot classify the product, and Product schema stays invalid.
Google's product structured data documentation treats the product name, image and offers information as required for product results; when brand, GTIN or availability is empty, the product does not appear on comparison surfaces. That is why we write the mandatory attribute list before the catalogue migration and measure the completeness rate against it. Google Search Central — Product structured data (opens in a new tab)
Do you work with clients outside Turkey?
Yes. The work is delivered remotely and English is the working language for documents, meetings and reports. Our office is in İzmit, Kocaeli, so on-site sessions inside Turkey are possible when a warehouse walkthrough or a workshop with your ERP supplier is useful.
Scope, acceptance criteria and reporting cadence are identical for clients inside and outside Turkey.
Who owns the code, the catalogue data and the platform accounts?
You do. The source code we write, the product data, the design files and the documentation are transferred to you at handover. Platform, payment provider, shipping and domain accounts are opened in your company name from the start, and we work on them with delegated access.
This matters at the end of an engagement: if the accounts are in the agency's name, migrating an e-commerce system means rebuilding it.
Questions about the working model, the contract and pricing are answered on the general frequently asked questions page.
See the measured state of your website within five working days.
The audit is free and creates no obligation to work with us. The report itemises findings on AEO answerability, AI crawler access, lab-measured Core Web Vitals, structured data validity and accessibility (automated scan).
We work with corporate-scale, multi-location or multilingual organisations. One-off small jobs fall outside our scope; in that case we point you to smaller studios.