Last updated:
Teclisa: A Phased B2B Commerce Platform for a Multi-Company Distributor
How Elogic Commerce took a 500,000-reference catalog, a Telematel Go!Manage ERP and a Sales Layer PIM into a live BigCommerce B2B storefront by shipping a deliberately narrow pilot first.
Project Summary
Teclisa is a Spanish distributor of electrical, climate and sanitary supplies operating through several trading companies, each tied to its own logistics warehouse and its own network of local points of sale. Customers buy on account, at their own negotiated prices, across a catalog of roughly half a million references. None of that was online.
Elogic Commerce led discovery, solution design and delivery of Teclisa’s first B2B commerce platform on BigCommerce, integrated with the Telematel Go!Manage ERP and the Sales Layer PIM through a custom middleware built by Elogic Commerce. The defining decision was to compress the original specification into a pilot: one warehouse, one customer segment, the native BigCommerce customer area with no custom front end, and a middleware limited to synchronization only. Everything that did not serve early production traffic was pushed into later phases with an explicit reason.
The store is live at teclisa.com.
Key Outcomes
60%
of orders now placed online. A business that took every order through a representative or a counter now routes the majority of its order volume through self-service.
7%
of total company revenue through the platform in the first three months. Achieved from a standing start, with no prior digital sales channel.
~ 500,000
references synchronized from PIM to storefront. Product data, attributes, media and grouping flow from Sales Layer into BigCommerce through the Elogic Commerce middleware.
Custom development
stayed with what couldn't be solved natively: the pilot shipped on the native customer area, promotions, search, wish lists and checkout, with custom work limited to the middleware, the parent–child product model, and a few template changes.
About the Client
Teclisa supplies professional installers and trade customers across Spain. The business is structured as a group of trading companies, each associated with a warehouse for stock and one or more warehouses for shipping, and each with its own list of local delegations that hold secondary stock and act as collection points.
Customers are commercial accounts, not consumers. A single client company can have multiple named users, and each user is linked to a commercial representative whose identifier determines which company and which warehouse serves that account. Pricing is negotiated per client rather than published, and a large share of trade is conducted offline through representatives, with invoices and delivery notes living in the ERP.
That structure is the reason a standard B2C commerce build would not have worked here. Almost every storefront behavior, from the price a user sees to the warehouse an order is routed to, depends on who is logged in.
Project Complexity
Roughly 500,000 references, with attribute quality varying widely across product families.
Sales Layer held product and related-product information but nothing that identified which fields define a variation. A safety boot has size and color; a sanitary set has components that are not variants at all but must be purchasable individually.
Product grouping and the attributes to display in comparison tables lived in an internal Teclisa spreadsheet that had to be merged with PIM data at import time.
Stock exists in warehouses and in points of sale, and what a given customer should see depends on the company their representative belongs to.
Prices are not derived in the storefront. The ERP is the only system that knows the final price for a client and product pair.
Customers expect to see orders, quotes, invoices and delivery notes that were never placed online.
Pallets, boxes and individual units carry different prices, minimum quantities and multiples, and sometimes require conversion before an order reaches the ERP.
Card and wallet payments matter, but so does paying on account and settling outstanding invoices.
Business Challenge
01
No digital sales channel for a business built on repeat trade orders
Every order passed through a representative or a counter, which capped throughput and tied experienced commercial staff to routine reordering.
02
Product data that could not be published as it stood
The PIM could feed a catalog, but not one where a buyer could compare sizes, formats or components of the same family in a single view.
03
Availability that could not be answered generically
A trade buyer’s first question is when they can have the item. Answering it required stock per warehouse, stock per point of sale, and the logic linking a user to the warehouse that serves them.
04
Pricing that could not be replicated in the storefront
Publishing list prices would have been commercially wrong. The platform needed to render the client’s own agreed price on every product view.
05
A customer account area that would be judged against the ERP, not against other web shops
Customers already had a complete commercial history. A portal showing only online activity would look broken.
06
A specification broad enough to delay any launch indefinitely
The original scope covered multi-warehouse logic, a customized buyer portal, offline order and delivery note surfacing, returns workflows, a B2C storefront and third-party search. Delivered as a single release, it would have pushed first production traffic far into the future.
Elogic Commerce's Solution
Reframing the scope into a pilot
Elogic Commerce restructured the program into four phases and defined Phase 1 as the smallest configuration that could carry real orders: a single warehouse, customers served by that warehouse, the native BigCommerce customer area with no custom front-end development, and a middleware responsible for synchronization only. B2C was removed from the first release. Multi-warehouse logic, offline order and delivery note surfacing, repeat order, returns and the third-party search engine were each assigned to a later phase with a stated dependency.
The purpose was not to reduce the project. It was to get production feedback before committing engineering effort to the parts of the specification that carried the most assumptions.
A parent and child product model in place of variants
Because the PIM carried no variant definition, Elogic Commerce implemented a two-level product structure. A parent product acts as a non-purchasable grouping page: image, title, descriptive attributes, and a table of the products grouped beneath it. The table renders SKU, image, name and the significant attributes for each child, with quantity entry and add to cart in the row. Clicking through leads to a full child product page with complete purchasing functionality, plus views of the rest of the group and of related products.
Grouping is driven by a product grouping code and by designated attribute and value fields sourced from Teclisa’s spreadsheet and merged with Sales Layer data during import. The storefront never needs to know whether a group represents variants or components. It renders whatever shares a grouping code.
A synchronization middleware between BigCommerce, Go!Manage and Sales Layer
Elogic Commerce designed and built the middleware that carries data between the three systems, including its hosting, CI/CD, authentication between BigCommerce and the ERP, database structure and a documented API layer.
Product and category data flow from Sales Layer to BigCommerce on a scheduled job. Stock flows from the ERP, with main warehouse stock, alternative warehouse stock and point of sale stock stored separately so the storefront can present each differently. Customer records synchronize in both directions, with B2B accounts always originating in the ERP and validated manually by Teclisa. Customer rates are imported from the ERP so that every logged-in user sees their own agreed price. Orders placed in BigCommerce are collected and pushed to the ERP, routed to the correct company. Invoices generated in the ERP are pushed into BigCommerce along with payment information.
Availability presentation built for trade buyers
The product page shows a dedicated availability block for authenticated users: stock in the warehouse that serves them, stock in other warehouses for information only, and stock in associated points of sale where the customer can collect in person. Points of sale appear only when they hold stock, and are presented as information rather than as a shipping method. Where there is no stock, the page shows an availability message fed from a PIM field rather than a generic out-of-stock label.
Native BigCommerce wherever native was sufficient
The customer area shipped native, including the Invoice Portal. Because invoices are pushed from the ERP with payment data attached, customers can view and settle invoices generated by offline orders through native functionality alone. Promotions, quantity discounts, wish lists, favorites, product lists, address book, returns, quotes and multi-user account management were all delivered on native BigCommerce behavior. Search shipped native in the pilot, on the reasoning that it maximized compatibility with the per-customer rate system.
Custom front-end work was limited to the availability block, the parent and child product tables, product feature icons rendered from metafields, and a free shipping progress counter in the cart.
Design within template constraints
The storefront design was built from a BigCommerce theme selected against Teclisa’s identity manual, with a custom home page assembled in PageBuilder and adjustments to product listing, product detail and cart pages. The constraint was deliberate: anything added had to remain editable by Teclisa’s own team through PageBuilder, with no structural modification to the theme that would create a maintenance burden later. A megamenu was implemented to handle the category depth the catalog required.
Payments, checkout and compliance
Payment methods cover PayPal, Redsys card and Bizum, payment on account for clients flagged with credit in the ERP, and bank transfer. Checkout was left standard, which keeps the platform inside BigCommerce’s PCI DSS scope. Data in transit is encrypted between the storefront, the middleware and the integrated systems, and the platform was implemented against GDPR requirements for consent, personal data management and deletion.
Results & Business Impact
Commercial
Teclisa now sells online to trade customers at their contracted prices, with the same account structure, credit terms and warehouse routing that govern their offline relationship. Routine reordering moved to self-service, which frees commercial representatives for work that requires them.
Operational
The ERP remains the system of record. Prices, stock, customers and invoices are authored where they were always authored, and the storefront reflects them. Teclisa's team manages content, promotions and page structure directly through PageBuilder and the BigCommerce backoffice without engineering involvement.
Technical
The integration layer is documented, environment-managed and built to extend. The phases deliberately deferred in the pilot, multi-warehouse logic, offline order and delivery note surfacing, repeat order and returns, have defined places in the architecture rather than requiring a rebuild.
Strategic
Teclisa reached production on a platform whose remaining roadmap is informed by live customer behavior rather than by pre-launch assumption. The pilot answered questions about availability presentation, product grouping and catalog quality that no specification document could have settled.
Capabilities Demonstrated
01
BigCommerce B2B implementation for a multi-company distributor
02
ERP integration with Telematel Go!Manage
03
PIM integration with Sales Layer, including reconciliation with a secondary client data source
04
Custom middleware architecture, build and API documentation
05
Large-catalog data modeling, including a parent and child product structure in the absence of PIM variant data
06
Per-customer pricing and customer group architecture driven from an ERP
07
Multi-warehouse and point of sale stock visibility logic
08
Phased scope design, including deliberate deferral with stated dependencies
09
UX and UI design within theme and PageBuilder constraints, with client-editable output
When This Solution Is a Good Fit
01
Your ERP can serve final per-customer prices and stock by location, and can answer with only what has changed since a given timestamp.02
Your product data lives in a PIM, even an incomplete one, and you can identify a secondary source for whatever the PIM does not hold.03
You are willing to accept native platform behavior in the customer area in exchange for a faster first release.04
Your commercial model depends on authenticated pricing, credit terms and account structure rather than on public catalog browsing.05
You have internal IT capacity to participate in integration work and to own content management after launch.06
You can define a first release narrow enough to reach production, and hold the line on it.Planning Your B2B Commerce Platform?
If you are weighing a B2B build against an ERP with per-customer pricing, a large or uneven catalog, and a commercial model that runs through representatives, the hardest decisions happen before development starts. Which parts of the specification earn custom development, and which are answered by a platform's native behavior, is a question worth resolving with someone who has made those calls under real constraints. Talk to Elogic Commerce about scoping your B2B commerce platform.