Parts Network
Overview
Context
CDK is an end-to-end SaaS company that has provided enterprise software to automotive dealerships across North America for more than 50 years.
Parts Network was an initiative to launch the industry’s first fully integrated parts marketplace connecting dealerships to a real-time network of suppliers, buyers, and logistics providers.
To position CDK as this pioneer, we set out to design a seamless purchasing experience leveraging the Dealer Management System (DMS) workflow. We wanted to enable service advisors and parts managers to quickly find and source the parts needed to complete repairs, reduce downtime, and serve more customers (make more money).
Solution
The new shopping experience was embedded directly into existing workflows and offers users a side sheet experience to source out-of-stock parts without leaving their current page. We add the needed parts and automate the quantities, leaving the user to select who they want it from. After orders are placed, we leverage existing order management to track shipping and fulfillment in a familiar way.
Into the nitty gritty
I want to quickly buy parts so that I can service more vehicles in order to increase turnaround.
Constraints
Some strengths of part network are also its constraints.
It’s a bit of a unique experience due to it being embedded, so there’s not a large dedicated footprint.
We know the specific part that’s needed so there’s no browsing, but a sequence of sourcing parts.
We also know the exact quantity needed and the use case dictates users are ordering for a purpose (fulfilling a customer need), so there’s no ordering excess parts.
Onboarding
The main goal was to get users up and running as fast as possible, while having enough rules where they could feel confident the automatically generated list would be what they want to sell.
Main problems solved:
A way for users to choose their use case; buyer/seller/both
A dashboard where users can see trends and metrics
A way to manage what is being sold and fine-tune listings
Access the shop
I designed the core shopping workflow as an embedded experience that’ prioritizes speed (time to order) and consistent behavior in each workflow.
There were 2 product “must-have’s”.
The CTA had to “pop” 😉
The shopping experience could not interrupt a users current workflow by taking them to a new screen.
For the CTA, a primary use case is shopping for parts the user cannot fulfill. In order to direct users to shop when necessary, we only surfaced the CTA after an out-of-stock part is added to an order or service. It’s a variant of how notifications are delivered (this one really pops!) and allowed for a low effort implementation that can be delivered consistently to different workflows..
For shopping, using a side sheet fit best vs. something like a large modal. In our system it allowed more functionality, better handled the longer workflow, and could more easily translate to mobile.
Shopping cart
I designed a seller-first shopping experience where users evaluate sellers instead of parts. By the time users enter the workflow, the “what” is known and the system has already identified the parts needed. The decision then becomes where to source those parts from.
For each part, multiple sellers offer the same item. The challenge was enabling users to quickly determine which seller could best fulfill their needs. Through user research, we identified the signals that most strongly influenced purchase decisions.
2 main factors stood out:
Inventory visibility - Users want to know available quantities without having to call and ask.
Distance to the seller - Proximity was synonymous with delivery time, impacting repair turnaround time.
Additionally, users strongly prefer sourcing all required parts from a single seller so shipments arrive together and end-stream workflows are simplified. To support this, the system identifies sellers capable of fulfilling the full set of required parts.
To further reduce friction points, inputs are pre-filled matching the add quantity to the required quantity. This is made possible from the main use case; shopping is triggered by out-of-stock parts tied to a specific job.
Completing the order
After adding parts, moving to checkout, choosing shipping types, etc., the orders are created, the side sheet closes, and the user returns to their main workflow.
Under each shopped part, the opportunity to shop identifier changes to a confirmation. The CTA changes to a standard notification where users can view the transaction receipt. At this point, orders and their payment are managed in a different workflow and the target user can move on to the next order.
Reflection And Future Goals
One opportunity for improvement is moving from part-by-part purchasing to full-cart solutions.
While the current experience helps users quickly evaluate sellers for individual parts, it still requires building a cart one part at a time. Given that technicians prioritize speed and prefer sourcing as many parts as possible from a single seller, a stronger solution would surface sellers that can fulfill the entire order upfront.
This would shift the experience from part-level decisions to cart-level optimization, reducing steps and accelerating checkout.
Longer term, this capability is intended to evolve into a dedicated marketplace experience outside the core software suite, expanding the platform into a broader ecosystem connecting repair shops and suppliers.