The sales desk opened at 8am. By 8:15 the phones were going. Dealers calling to check stock. Calling to place orders. Calling to get an updated price. Calling because someone had promised a discount they needed confirmed in writing.

Three people handled all of it. Orders came in verbally and had to be typed into the system manually. A dealer who called at 11am on a busy day might not get a confirmation until 2pm. Friday afternoon: wait until Monday.

This was not a customer service failure. It was a structural one. No portal, no account login, no way to check stock at midnight before placing a morning order, no way to reorder a previous job without calling in the full specification again.

Pricing added friction. Every account was on a different rate structure negotiated at different times. Some had category-specific discounts. Some had volume thresholds that unlocked better rates mid-order. None of it was visible to the dealer. They placed an order, got an invoice, and sometimes queried the price because they could not see the logic behind it.

Credit requests and returns were another category of call that added nothing to anyone's day. Dealer calls. Sales desk raises a credit manually. Tracked inconsistently. Slower than it needed to be.

The real cost was the ceiling. The distributor could not grow the dealer network without growing the sales desk headcount proportionally. Every new account meant more calls. That is not a scalable model.

Tiles IT Solutions built a custom B2B dealer portal on BigCommerce, with a React front end tailored specifically to how tile dealers actually buy: by product line, by shade lot, by stock availability, and always against their own pricing.

Every dealer account in the system has a dedicated login. When a dealer logs in, they see their own version of the catalogue. Not a generic price list. Their prices, calculated live from the pricing rules attached to their account. If they qualify for a volume discount at 50m², the portal shows them the break price before they reach it, with a running total that updates as they add products. The pricing conversation on the phone stopped because the portal made the pricing transparent.

Stock display was built to show real position, not a generic in-stock or out-of-stock flag. Dealers can see available quantity, which warehouse it is held in, and whether there is additional stock on an inbound delivery and when it is expected. A dealer planning a job six weeks out can make an ordering decision based on actual information rather than calling to ask.

Reordering is one click. Every previous order is in the account history with the full product specification, shade lot, quantity, and price paid. A dealer who ordered 80m² of a specific porcelain for a project six months ago can find that order, verify the shade lot is still available in stock, and reorder in under two minutes without spelling out the product code to a sales rep.

Credit requests and returns were moved into the portal entirely. A dealer submitting a credit request fills in a short form with the order reference, the issue, and if relevant, a photo. The request goes directly to the accounts team with all the information already attached. No phone call, no back-and-forth, no trying to track down the original order number.

The implementation challenge was pricing data. The distributor's account pricing had been maintained across a combination of spreadsheets and notes in the CRM, with no single consistent structure. Some accounts had discounts expressed as percentages. Others had fixed prices per SKU. Others had category-level rules with SKU-level exceptions. Before the portal could show any dealer their correct price, every account's pricing logic had to be extracted, audited, standardised, and imported into BigCommerce's price list structure. It took longer than building the portal. But a dealer who logs in and sees the wrong price will not log in again.

Redis handles session-level pricing caching so the portal does not call the pricing engine on every page load. Docker keeps the deployment containerised and consistent across environments. PostgreSQL holds the full order history and account data that the portal surfaces to each dealer.

Before: Dealer needs to check stock. Calls the sales desk. Gets put on hold. Eventually speaks to someone who opens the same stock system the portal now shows directly. Dealer places the order verbally. Rep types it in. Confirmation goes out hours later. Friday afternoon: nobody picks up. Order waits until Monday.

After: Dealer logs in at 10pm, checks stock across two warehouse locations, sees that the shade lot they need has 120m² available and another 200m² arriving in eight days. Adds to cart, sees their account pricing with the volume break applied at 60m², checks out. Confirmation in their inbox before they close the laptop.

• 80% of phone orders moved to the self-serve portal within four months of launch, freeing the sales desk from the order-taking function entirely
• Dealer-specific pricing visible at login, with volume breaks and category discounts displayed in real time as dealers build their basket
• Live stock visibility across warehouse locations replaced the stock-check phone call for every dealer in the network
• One-click reordering from full order history cut the time dealers spend rebuilding previous specifications from scratch
• Credit requests and returns fully self-serve, removing a category of inbound calls that added no value to the sales team's day
• Distributor headcount decoupled from dealer network growth, adding new accounts no longer requires adding sales desk capacity proportionally

The phone line is still there. Dealers call when they have a genuine commercial conversation to have. What they do not call about anymore is stock, pricing, reorders, and credit requests. Those four things were the bulk of the volume. Moving them to the portal did not shrink the relationship with the dealer network. It just moved the conversation to the things that actually need a person.