In a setup where orders arrive by phone and WhatsApp, sales is only as solid as the memory of whoever remembers. We build a portal that shows each dealer their own discount, current stock and account balance — and drops the order straight into your ERP. The same platform serves a domestic dealer network and an exporter loading containers out of Başpınar alike.
Prepared by Pan Innovation House, a software company based in Gaziantep, Türkiye · Last reviewed:
We are based in Gaziantep, Türkiye, with a London office at Unit 6 Cranford Way, Hornsey, London N8 9DG. On-site discovery covers plants in and around Gaziantep; elsewhere in Türkiye and abroad it starts by video call and a visit is planned if needed. The first 30-minute call is free; the scope of an on-site discovery, and its fee if any, is agreed in writing during that call.
We can show a B2B portal approach — dealers log in to their own prices and open their own orders — on a working example during discovery; we do not name clients without their consent. You won't need every piece below; we choose based on your dealer count and the way you sell.
When a dealer logs in, they see only their own prices. Price groups, product-level discounts, tiered quantity discounts and campaign rules are written into the system. The price no longer lives in a circulating Excel file; it sits in one place, and the moment you change it, it applies to everyone.
While ordering, the dealer sees what is on hand, how much is reserved and when production will deliver. For a product out of stock, a forward order can be opened against a promised date. The 'I placed the order but it never came' conversation gives way to a conversation about dates.
The catalogue and the order screen open in multiple languages, and prices are shown in the dealer's currency. The rate source and the rule for which rate applies work to your definition. Proformas, delivery terms and the required product details are generated from the order; no document is written from scratch for each export order.
The dealer sees their balance, invoices falling due and payment history on their own screen. How the order flow behaves when the credit limit is exceeded — whether it stops or routes to approval — is set up to your decision. Chasing collections stops being a game of mutual reminders.
Your existing system — Logo, Mikro, Netsis — stays where it is. Products, prices, stock and accounts come from there; an order opened in the portal lands there as an order. Entering the same data into two places by hand disappears. We build the integration through the route your system's vendor supports (API, service layer or an approved import); we do not write directly into its database tables.
A dealer can open a past order on their phone and repeat it with a single tap. Your field rep, meanwhile, can enter an order on the dealer's behalf from the same screen, right in front of the customer. The step of returning to the office after a visit to retype the order disappears.
Your dealer types, price groups, discount logic and exceptions are laid on the table. At this step, most companies see their pricing rules put in writing for the first time; even if no portal were built, that output stays with you.
Product cards, units, per-carton quantities, pallet tiers, images and stock data are reviewed. Missing and inconsistent records are cleaned up at this stage, because the portal shows ERP data straight to the dealer's eyes. Then the two-way integration is built.
The portal opens first to a limited number of dealers. We usually pick the ones that order the most and the ones that ask the most questions; each teaches something different. Screens and flows are simplified based on their feedback.
Dealers receive a short how-to and their login details. During the transition, we also enter phone orders into the portal ourselves and show the result on the dealer's screen, carrying the habit across. We never close the phone channel in a single day.
Which dealers use the portal, which are still on the phone, which products get left in the basket — all of it is tracked. Work continues under a maintenance and support agreement, and we add new markets or new languages when needed.
The answer lies in what the portal gives the dealer. If a dealer can see their own price, the stock, where their order is and their balance, using the portal is faster for them too. So we make the transition gradual rather than forced: pilot dealers first, then during the transition we enter phone orders into the portal ourselves and show the dealer the result. Habits start to change once the screen proves useful.
The portal is not a shop window open to everyone. Each dealer logs in with their own account and sees only the prices defined for them; no dealer can see another dealer's discount. Price visibility can be switched off entirely for visitors who are not logged in. Who viewed which screen and when is also kept on record.
A retail site and a dealer portal do different jobs. Retail means one price, a basket and card payment; the dealer side means customer-specific prices, tiered discounts, carton and pallet multiples, credit limits, open accounts and payment terms. Forcing retail infrastructure into the dealer arrangement usually breaks both. If needed, the two can be connected so they share the same product and stock source.
No. Your accounting backbone stays as it is. The portal takes product and stock information from it and writes new orders back into it. We build the integration through the route your system's vendor supports (API, service layer or an approved import); we do not write directly into its database tables. If no suitable route exists, we say so up front and set out the alternative and its limits clearly in writing.
The catalogue, the order screens and the notification texts are kept in multiple languages; each dealer sees their own. Prices are shown in the dealer's own currency, and the rule for which rate and which date apply works exactly as you define it. Proformas and delivery terms are generated from the order, lifting the burden of retyping the same information at the export desk.
Yes, during discovery. We can show a B2B portal where dealers log in to their own prices and open their own orders, together with the stock and order link behind it, on a working example. We do not name clients without their consent, and we do not invent result figures.
The duration depends not on the number of dealers but on the state of your product data and integration. Most of the time goes into fixing product cards, units and per-carton quantities. So we start the job with discovery, plan data preparation as its own step, and go live with pilot dealers. A proposal that quotes a number of days up front has usually never seen this step.
The source code we write and your data are handed over to you as defined in the contract. It can run on your own server or on a provider you choose. Your dealer list, your prices and your order history are your commercial assets; locking them into a supplier's system would be wrong.
B2B (business to business) is the trading model in which a business sells its product or service not to consumers but to other businesses, such as dealers, wholesalers or corporate buyers. B2B sales come with rules such as customer-specific prices, tiered discounts, carton and pallet multiples, credit limits and payment terms. In the dealer portals we build, each dealer sees only their own prices, current stock and account balance, and enters their own orders.
Let's spend a day at your order desk and count together: how many orders came in by message, how many were entered at the wrong price, how many bounced back because of stock. Once you see the number, you decide whether a portal is worth it to you. We come to Başpınar OSB and Şehitkamil.
