Search creates a fragile piece of judgment
A salesperson can reduce hundreds of vehicles to three plausible candidates in a few minutes. That shortlist contains more than search criteria. It reflects what the customer rejected, which tradeoffs they accepted, and which units deserve the next conversation. If the candidates exist only as highlighted cards in the current tab, all of that judgment disappears when the employee changes desk, device, store, or browser session.
Repeating the filters is not equivalent to recovering the decision. Inventory may have changed, the original order may be different, and the employee may no longer remember why two nearly identical units were treated differently. The product needed a lightweight way to preserve the candidates without pretending that a pin is a reservation or a deal record.
A pin needs two scopes
LotPro synchronizes pinned vehicles under the employee and active store. Employee scope prevents one person’s working set from becoming a shared default for the whole dealership. Store scope prevents a unit selected in one inventory context from appearing as though it belongs to another. The result is personal working memory with a clear dealership boundary.
The cloud-backed hook listens for changes so a supported second surface can receive the updated set without requiring the employee to export or copy a list. That synchronization is intentionally narrower than sharing. Another employee does not inherit the pins unless a separate workflow explicitly turns the shortlist into a chat, quote, task, or customer presentation.
- Personal to the signed-in employee
- Separated by active store
- Synchronized instead of bound to one browser tab
- Available as context for a deliberate next action
Sorting cannot erase unusual inventory
A durable shortlist still has to survive the messy values found in dealership feeds. Some units use call-for-price rather than a numeric amount. Treating that text as zero would send those vehicles to the top of a lowest-price sort and distort the comparison. The inventory work added robust numeric parsing and deliberately places non-numeric or zero-like price values after real prices in both sort directions.
The interface also replaced ambiguous arrow labels with plain-language options such as Highest Price, Newest Year, and Lowest Mileage. That may sound small, but a saved decision is only useful if the employee can reconstruct how the candidates were ordered. Clear sorting language makes the comparison explainable rather than merely repeatable.
A bug revealed the value of the boundary
The initial pinned-inventory work exposed a runtime crash when stores already had pinned items. Undefined setters were being passed through object construction even though the new hook owned the behavior. Removing those stale references repaired the view and clarified which layer was responsible for synchronization.
That incident is worth recording because persistence features often look finished in an empty demo. The meaningful case is returning to an existing working set. A shortlist must load safely when it already contains data, update without losing the current view, and remain scoped when the store changes. The repair moved the feature closer to that real condition.
What the evidence supports
The implementation, production build, and runtime crash repair are recorded. The product can truthfully describe per-employee, per-store pinned inventory with real-time synchronization. It cannot truthfully attach a measured time-savings claim, promise reservation semantics, or present the dated work as a formal multi-device field study.
The intended result is simple: the strongest vehicle candidates can follow the salesperson into the next supported conversation instead of being rebuilt from memory. Rollout validation should now test conflict behavior, store switching, removed inventory, and the handoff from a private shortlist into shared work. It should also make disappearance legible. If a pinned unit leaves the active feed, the product must distinguish unavailable inventory from a synchronization failure and let the employee understand why the working set changed.