Sell digitally

Reach more customers

Serve the long tail your field sales team can never economically reach.

Your sales team calls the accounts worth calling. Everyone below that line (the occasional buyer, the small regional workshop, the project purchaser who needs you once) is unprofitable to visit and gets served badly or not at all. A shop has no such threshold. The thousandth customer costs roughly the same to serve as the tenth, and it takes the order at 22:30 on a Sunday.

Why this is harder than it sounds

The long tail is unprofitable because of cost to serve, not because of price. Putting a shop in front of it only helps if the whole cost disappears. If every new small account still needs a person to create master data, run a credit check by email, and assemble a price list by hand, you have moved the cost from the phone to the back office. The test is blunt: can a company you have never heard of place a valid, priced, deliverable order without anyone at your company doing anything? Until the answer is yes, the tail stays unprofitable.

Then there is findability. Your existing customers search by your article number because they have your catalogue on the shelf. A new buyer has never seen it. They search for Verschraubung Edelstahl G 1/2 10 bar, an attribute description, not an identifier. If those attributes live inside a free-text description field copied from the ERP, no search engine on the market can rescue you. This is a data-model problem wearing a search costume.

There is also a conflict you have to settle: B2B instinct is to put everything behind a login, and search engines cannot read what is behind a login. Prices are confidential; product data usually is not. Deciding which parts of the catalogue are public is a commercial decision, and postponing it means postponing every source of new demand.

Not all of the tail is small. Some of the accounts you cannot reach are large ones whose purchasing departments never visit supplier websites at all. No amount of SEO reaches them. That is a different lever entirely; see Connect customer procurement.

The levers

Make the catalog findable without a salesperson

What good looks like: a buyer who does not know your article numbers narrows a 40,000-article catalogue to five candidates using filters (thread size, material, pressure rating, norm) and can tell from the page which of the five is right. Search returns nothing useful only for things you do not sell.

What it depends on: structured attributes. Filters are generated from attribute values, so an attribute that exists only as words in a description cannot become a filter. This is the expensive prerequisite and the one most projects underestimate.

Let a stranger become a customer without a phone call

What good looks like: self-registration creates an organization with a default price list, standard payment terms, and a segment that marks it as unvetted. The first order goes through on prepayment or card. When the account proves itself, someone moves it to invoice terms and better conditions, as a decision rather than a bottleneck at the start.

What it depends on: having a defensible default price and a payment method that carries no credit risk. Without both, every new registration lands on someone's desk.

Be visible outside your own domain

What good looks like: product pages that a search engine can read and index, with the technical data on the page rather than only in a PDF; category and application pages that answer the question a buyer types; a second language where you deliver.

What it depends on: deciding what is public. It also depends on the catalogue being complete for the web channel. Half-finished pages that get indexed are worse than pages that do not exist.

Reach the accounts that will never visit your website

What good looks like: your catalogue appears inside the buyer's procurement system with their negotiated prices, and the order comes back as a normal order in your system.

What it depends on: customer-specific prices being reliably available, and product data clean enough for a machine. A procurement system rejects an order line with a missing unit of measure; it does not render it badly.

A sensible order

Phase 1: publish a findable catalog. No transaction, no login, no checkout. Model the attributes, load the products, get completeness to the point where a page is worth showing, and publish. This phase is worth doing even if you never build a shop: it produces inbound enquiries and it is the prerequisite for everything after it. It depends on nothing except your own product data, which is why it can start now.

Phase 2: let people register and buy. Add self-registration, a default price list, and a payment method with no credit exposure. Keep the first version narrow: one country, one currency, one storefront. Phase 2 depends on Phase 1. A shop over an unstructured catalogue produces orders for the wrong articles, and returns cost more than the orders were worth.

Phase 3: widen the reach. Punchout for the accounts that need it, a second language for the markets you can deliver to, marketplace or portal listings if they fit your channel policy. Every item here depends on the data being clean, which is why it comes last.

Decide who owns a new online account before you launch. The argument about whether the field sales representative for that postcode gets credited arrives with the first order, and if it is unresolved the organisation stops promoting the channel.

Common mistakes

Putting the whole catalogue behind a login and then wondering why nobody new arrives. Prices are confidential. Thread sizes are not.
Onboarding a 400 € account the way you onboard a key account. If a new customer costs half a day of back-office work, the tail stays unprofitable no matter how good the shop is.
Launching without a default price, so an unknown buyer sees "price on request" and leaves. A visible, defensible list price is what makes self-service possible at all.
Building the storefront before the attributes exist. The storefront is the last thing to build and the first thing everyone wants to start with.
Measuring traffic. Sessions mean close to nothing here. Distinct ordering accounts is the number.

How you know it is working

Set a baseline before you launch, then track monthly:

Distinct accounts that placed at least one order, split into accounts with an assigned sales representative and accounts without. The second group is the one this goal is about; if it does not grow, nothing else matters.
Orders that required no manual intervention between arrival and confirmation: no master data created by hand, no price looked up, no credit call.
Share of revenue from articles outside your top 200. Long-tail reach shows up as catalogue breadth before it shows up as revenue.
Registrations started versus completed. A gap here is a form problem or a vetting bottleneck on your side, and it is cheap to fix once you can see it.
Zero-result searches, ranked by frequency. This is the most honest list you will ever get of what buyers expect from you and do not find. See Trusting your numbers.

Move existing customers online, usually the larger and faster lever of the two.
Publish a digital catalog, Phase 1 above, treated as a project in its own right.
Connect customer procurement, for the accounts SEO will never reach.

What you're building

A public storefront whose product pages a search engine can index, backed by a catalog with typed attributes so buyers can filter their way to the right article. A stranger registers, becomes an organisation on a default price list with prepayment, and orders without anyone at your company doing anything. Later, the same catalog appears inside large customers' procurement systems through punchout.

flowchart LR
  WEB["Search engines, new buyers"]
  subgraph XS["Experience Studio"]
    SF["Storefront: public catalog pages"]
    REG["Registration form"]
  end
  subgraph CS["Commerce Studio"]
    P["Products: typed attributes"]
    CAT["Categories"]
    C["Customers: self-registered organization"]
    SEG["Segments: unvetted"]
    PR["Prices: default list"]
    PAY["Payments: prepayment, card"]
    O["Orders"]
  end
  subgraph IS["Integration Studio"]
    WF["Workflows"]
  end
  ERP["Your ERP"]
  PUN["Customer procurement system"]
  P --> CAT
  P -- "attributes become filters" --> SF
  WEB -- "indexes public pages" --> SF
  SF --> REG
  REG -- "creates" --> C
  C --> SEG
  PR -- "default price" --> SF
  PAY --> O
  SF -- "order" --> O
  O --> WF
  WF -- "order, new customer" --> ERP
  PUN -. "punchout, later" .-> SF
  SRCH["Search app (planned)"]:::planned
  P -.-> SRCH
  SRCH -.-> SF
  classDef planned stroke-dasharray: 5 5

What you need

Typed attributes for what buyers filter by, in the model before data is loaded — Attributes and attribute groups
A decision on what is public: catalog, list prices, or neither — What visitors see before they log in
The web channel's completeness rule met for the published assortment — Completeness and readiness
A defensible default price list for unknown accounts — Set a list price
A payment method with no credit exposure — Payment methods
A self-registration path that creates an organisation, a contact and a segment — Self-registration
A rule for who owns a new online account, agreed with field sales — Segments
A domain and a storefront that renders product pages for search engines — Domains and going live

Build it

Collect what buyers search for from sales and from search logs, and turn each into an attribute — Attributes and attribute groups
Load the assortment and take the top families to complete for the web channel — Import products in bulk
Decide what is public and configure the storefront accordingly — What visitors see before they log in
Create the storefront, connect the domain, and check that product pages render without login — Create a storefront
Build category and application pages for the questions buyers type — Edit pages and blocks
Create the default price list and the "unvetted" segment — Price lists
Configure prepayment or card as the payment method for that segment — Payment methods
Switch on self-registration and test it as a stranger, on a phone — Self-registration
Write down the account-ownership rule for field sales — Contacts and roles
Define when an account moves to invoice terms, and who does it — Approve a registration
Review zero-result searches weekly and fix the top ten — Trusting your numbers
Add the second language for markets you deliver to — Languages and markets
Set up punchout for the large accounts that ask — Set up a punchout

Decisions you'll need to make

Decision	The trade-off	Where most customers land
What is public? The full catalog with list prices, the catalog without prices, or a login wall.	Public prices bring the most search traffic and self-service orders, and dealers and competitors read them. No prices keeps the conditions private and turns "price on request" into the reason strangers leave. A login wall produces no new demand.	Catalog public, list prices public where there is no dealer network to protect, contract prices after login.
Does a stranger get a price? A default list price for all, or "on request" until vetted.	A default price lets a stranger order at 22:30. "On request" protects margin on the first order and loses most first orders.	A default list price with prepayment. The margin on a first small order is not what the tail is about.
Who vets a self-registration? Nobody, the Innendienst, or a rule.	No vetting means everyone orders on prepayment immediately. Manual vetting adds half a day to every 400 € account. A rule (segment plus payment method) vets nobody and risks nothing.	A rule: self-registered accounts land in an unvetted segment on prepayment, and somebody promotes them after the second order.
Who owns the new online account? The field sales representative for the region, the online channel, or nobody.	Crediting field sales keeps them on side and costs commission on orders they did not touch. Not crediting them makes the channel a competitor to your own people.	Crediting the regional representative for accounts above a size threshold, with the tail below it assigned to the online channel. Whatever the rule, written before launch.
Where does search come from? The storefront's built-in search over attributes, or a dedicated search app.	The built-in search works over typed attributes today. The Search app with synonyms, merchandising and analytics is planned and not on your tenant yet.	Attribute filters and the built-in search now; the Search app when it ships. The attribute work is the same either way.

Commerce Studio — Products · Attributes · Categories · Completeness · Organizations · Segments · Payment terms · Prices · Payment methods · Channels
Experience Studio — Sites · Pages · Domains · Languages and markets · Forms
Integration Studio — Workflows · Credentials · Outbound webhooks

Edit this page

Sell through marketplaces

Mercateo, Amazon Business, your own dealer portal: the same catalog, a different cut per channel.

Transform sales

Four levers for the customers you already have: get their orders online, make the orders larger, take quoting out of Outlook, and turn the repeat order into an arrangement.