The handoff is where the work gets expensive
A dealership conversation rarely stays inside one piece of software. The salesperson may discover a vehicle in the LotPro browser workspace, return to a lead in the CRM, call from an Android phone, and later bring the deal to a larger shared display. None of those transitions is unusual. The waste begins when each new surface asks the employee to reconstruct the same situation from memory.
Which stock number did the customer prefer? Was the next action a VDP, a payment comparison, or a follow-up task? Which store is active? The individual clicks are cheap; the repeated interpretation is not. Each handoff creates a small opportunity to select the wrong record, copy stale information, or abandon the thought that caused the handoff in the first place.
One context does not mean one giant interface
The tempting answer is to make every surface look and behave exactly the same. That would ignore why those surfaces exist. The responsive web workspace is where the modular operating tools belong. LotPro Companion sits beside supported CRM pages because the CRM record is already the center of that moment. LP Phone participates in Android Telecom because native call state, SIM selection, and post-call behavior cannot be reproduced honestly in a browser panel.
LotPro therefore divides responsibility while preserving the useful identifiers a supported handoff needs. A vehicle action should carry the selected unit. A CRM-side tool should start from the visible lead only when the adapter has verified that context. A call action should reach the native phone experience without pretending the dialer is another copy of the web app. Continuity is a contract between surfaces, not a promise that every module travels everywhere.
- LotPro: responsive and installable browser workspace
- Companion: focused actions beside supported CRM pages
- LP Phone: Android-native calling states and SIM-aware behavior
- Shared context only where the receiving surface can verify it
A useful relay has to fail closed
Passing context across products raises a second question: what happens when the receiving surface is not ready, the CRM page is unsupported, or the active record has changed? The safe answer is not to guess. Companion adapters have to recognize the current page and resolve only the fields they are designed to handle. Cross-frame messages need an expected origin and an explicit readiness acknowledgement; loading an iframe is not proof that its application is ready to accept state.
The same restraint applies to the phone. Device, Android version, carrier, and SIM configuration can change what the system permits. A remote relay that incurs ongoing infrastructure cost can also be disabled without removing local Android calling. These are not glamorous product decisions, but they keep ‘continuity’ from becoming a vague claim that silently degrades into the wrong record on the wrong screen.
What the employee should experience
When the boundaries work, the employee does not notice a heroic integration. They notice that the next surface opens with enough context to continue the decision. The vehicle remains the vehicle. The lead remains the lead. The call result can return to a visible next action instead of disappearing into a separate phone history. The interfaces can stay purpose-built because the person no longer has to serve as the integration layer between them.
This is the result LotPro is aiming to sell: not fewer screens at any cost, but fewer resets between screens. A specialist tool is valuable when it takes over the part of the job it understands and returns the employee to the same customer story.
Coverage today
The product system is pre-alpha. The web workspace, Companion, and LP Phone are distinct products with different release paths. CRM adapters do not have equal coverage, context handoffs are supported only on recognized pages, and controller navigation varies by module. The hosted Phone Relay is currently disabled for cost containment; that does not make every phone workflow unavailable, but it does limit remote control behavior.
Rollout validation should therefore begin with one concrete handoff and one supported environment. Proving that path is more useful than implying universal continuity before the adapters, devices, and operating controls have earned it.