Take a hypothetical pump repair scheduled for Wednesday. The bearing is due on Tuesday; the seal kit on Friday. Each order has a delivery date, but the maintenance team still has a problem: one of the parts will arrive after the planned shutdown.
That is where I want Parts Hub to begin: with the job that needs doing, its requirements and the commitments that will make it possible.
I have previously written about a connected electronic parts catalogue. Parts Hub takes that thinking into purchasing, stock and trading relationships. The scope is deliberately broader than automotive parts. The design should also make sense for a maintenance business, a contractor or a supplier buying the products it needs to fulfil another order.
This is the product direction I am developing, starting with a connected journey from a project requirement to the receipt of an order.
Start with a project and its requirements
My starting point is a project with a list of required items. Each line would carry a description, part number where known, quantity, unit of measure, destination and required date. A buyer could attach a specification or photograph and say whether an alternative is acceptable.
That last decision matters. A superficially similar part can create another round of questions. I want any proposed substitute to remain a visible choice for the buyer to approve, with the original requirement preserved.
Suppliers could respond against individual lines or offer a package. The buyer would see what is covered, what is still missing and which delivery commitment affects the whole job. Splitting an order between suppliers might be sensible; the interface should make the additional freight and coordination visible.
The project then becomes a shared reference point through quoting, ordering and receiving. A late item has context: this is the work waiting for it, and this is the person who needs an update.
Let a business buy and sell
A key choice in the design is allowing the same business to be both a customer and a supplier.
A distributor could sell stock to one business while buying replenishment from another. A repairer might buy everyday consumables and offer surplus parts. These activities should sit within one organisation account, with clear purchasing and sales views.
People would receive permissions for the work they do. A staff member might maintain listings, another prepare purchase orders, and an owner approve a larger commitment. The trading relationship belongs to the organisation, while actions remain attributable to the person who took them.
I also want a straightforward connection between a buyer's purchase order and a seller's sales order. They represent opposite sides of a transaction, with related references and agreed details. A change to quantity or delivery should have an explicit acceptance step so both parties can see which version they are working to.
Make stock information useful enough to trust
The first stock screen can be simple: part number, description, category, quantity and price. Useful trading needs a little more precision.
I would distinguish the manufacturer's identifier from a supplier's own code, record the selling unit and show when availability was last updated. Ten individual fasteners and ten boxes of fasteners need different treatment throughout a quote and an order.
Established identifiers can help. GS1's Global Trade Item Number identifies trade items across supply chains. Where a GTIN is available, I would retain it alongside other identifiers. Matching a name alone would be insufficient for the system to declare two products interchangeable.
Availability also needs a clear meaning. Stock on hand, stock already committed and stock awaiting supplier confirmation should be distinguishable. For the first release, I would show when availability was updated and ask the supplier to confirm it before the buyer commits.
Give pricing a relationship and a context
The initial pricing idea includes a reference price and bronze, silver and gold customer levels. I want those levels attached to a supplier's relationship with a customer. A business could qualify for one supplier's gold terms while trading with another on different terms.
The quote should show the applicable price, unit, freight, tax treatment and validity period together. That gives the buyer a basis for comparing the whole commitment.
The demand side is where this becomes more interesting. A buyer could publish a request for the items a project needs and invite offers. A reverse auction could be an optional format for suitable requests, with suppliers competing on an agreed scope. I would keep ordinary quotation available as well.
The buyer would retain the choice of offer. Delivery confidence, condition and an approved substitute may matter more to a particular job than a small price difference. Conversely, a supplier with a scarce or unusual item could offer a conventional auction, with its own clear closing and acceptance rules. Those are distinct workflows worth testing separately.
Make the network useful without exposing every relationship
The social element I want is purposeful: business profiles, supplier discovery, project discussions and a record of agreed actions. People should be able to find each other and resolve a question where the relevant item is visible.
Familiar sign-in providers could make joining easier. OpenID Connect supports sign-in through an identity provider. Parts Hub would still need to establish which organisation that person represents and what they are allowed to do there.
A public profile would not make negotiated prices or private project conversations public. I want visibility to be understandable at the point someone shares something, with appropriate checks on every request for private data.
The job is the test
My preferred first test is modest: one buyer, a project, a few suppliers and one order carried through to receipt. Can the buyer request the right items? Can suppliers answer without retyping everything? Does an accepted quote become an unambiguous order? Can both sides handle a short delivery?
In a pilot, I would measure time to a usable quote, how many requirement lines receive suitable offers, discrepancies at receipt and whether participants choose to return.
When the shutdown starts, the maintenance team needs the correct parts at hand and a clear answer about anything missing. That is the outcome I would build Parts Hub around.