Decision resource · 08 · Online edition

Service Terminal Evaluation and Procurement Guide

Questions, requirements, risks, and approval criteria for dealership buyers

Evaluate the operating mechanism, technical boundary, evidence quality, and lifecycle - not a category label.

AudienceProcurement, corporate operations, dealership IT, fixed operations directors, and legal and risk reviewers
Decision questionWhat should a dealership evaluate before buying workflow technology?
Document length9 substantive sections

Service Terminal is dealership workflow infrastructure that provides a restricted access point for authorized existing workstation sessions. It extends an approved environment closer to service work and does not replace the DMS, OEM systems, diagnostic tools, repair-order process, or dealership controls.

Section 01

Business and operational requirements

Begin with the repair-order transition and role that require improvement. A broad efficiency objective is not specific enough to evaluate.

Document current volume, physical path, access queue, transition timing, affected role, existing workstation dependency, and decision owner. State whether the requirement is reduced movement, reduced waiting, less relay, faster resumption, improved late-day progression, or another observable condition.

The product should be evaluated against the named problem without credit for delays caused by unrelated staffing, parts, authorization, scheduling, demand, or facility constraints.

Business requirements

Named service workflow and transition
Intended roles, locations, and approved sessions
Baseline definition and evidence source
Success, stop, and exception criteria
Executive and operating decision owners

Section 02

User and role requirements

The correct access pattern differs for technicians, advisors, foremen, managers, and support staff. Procurement should preserve least privilege rather than normalize shared credentials.

Ask whether the product extends the user's existing workstation workflow or creates a parallel record. Confirm how the active user is identified, what local interface is available, how the session ends, and how physical placement affects safety and privacy.

Require role-based orientation and a process for reporting connection failure, target unavailability, certificate warnings, credential issues, and unexpected local behavior.

Role requirement worksheet

RoleAuthorized taskExisting targetPlacement / privacy need
Technician________________________________________________
Advisor________________________________________________
Foreman / dispatcher________________________________________________
Manager________________________________________________
IT / support________________________________________________

Section 03

Architecture, credentials, and data handling

Require a component-level explanation that distinguishes core operator traffic, optional management traffic, local operational state, and dealership-side dependencies.

The current Service Terminal implementation launches outbound RDP sessions to approved targets. The password is entered locally, passed directly to the session process, and cleared from the interface; the application does not persist the password. Username history, logs, network profiles, inventory and discovery state, device-lock state, and optional device-service state may exist locally.

Ask what dealership data is stored locally, whether credentials are stored, how state is protected and removed, which traffic is required, and which controls depend on the deployed operating-system image.

Evaluation boundary

EmployeeSelects approved target and enters credentials
Managed terminalApplies local policy and launches client
NetworkCarries approved outbound connection
Existing workstationRuns dealership-authorized environment
Optional servicesUse separately approved outbound HTTPS

Section 04

Network, trust, and redirection questions

The review should test actual commands and fallback paths, not rely solely on a feature summary.

Document required ports, DNS, DHCP, NTP, segmentation, proxy behavior, optional management endpoints, and any administrative exception. Core RDP normally uses an outbound connection to an approved target; an example optional support configuration can permit inbound SSH and should be treated as a separate dealership decision.

The primary command disables clipboard directions. A compatibility retry is built from a base argument list that does not include the same explicit clipboard-off option, so the dealership should validate and remediate that path before asserting that clipboard control is invariant.

Network and session review

QuestionExpected evidenceDecision
Which directions and ports are required?Flow table and observed test________
How are certificates evaluated?Mode, enrollment, and change test________
Which resources can be redirected?Primary and fallback command review________
What happens when network is lost?Observed session and recovery result________
How is optional administration controlled?Separate approved exception________

Section 05

Endpoint controls, updates, and removal

Evaluate the complete deployed image because kiosk controls span application code, install scripts, system services, compositor policy, input controls, and physical configuration.

Ask how updates are built, approved, delivered, logged, tested, rolled back, and supported. Confirm who owns patching for the operating system, client packages, certificates, optional device services, target workstations, and dealership applications.

Removal should cover the device, management identity, local state, logs, network exceptions, support access, inventory record, and physical disposition. The existing dealership workstation and applications should remain available independently.

Lifecycle requirements

Restricted interface and physical-access review
USB, input, VT, compositor, and watchdog validation
Update owner, cadence, evidence, and rollback
Support boundaries and incident escalation
Disablement, removal, local-state handling, and disposal

Section 06

Security evidence and shared responsibility

No certification, audit, or control should be inferred from an architecture description. Require evidence appropriate to the dealership's risk process.

Separate product defaults, installation controls, optional settings, and dealership-side controls. Service Terminal does not replace identity governance, target authorization, workstation hardening, network segmentation, certificate lifecycle, physical security, monitoring, retention, or employee policy.

Request current architecture and data-flow documentation, implementation-backed control descriptions, build and update evidence, a residual-risk record, incident contacts, and an explicit list of dealership configuration responsibilities.

Control evidence matrix

Control areaProduct evidenceDealership evidence
Identity and credentialsHandling path and testsUser lifecycle and target rights
EndpointImage, scripts, and control testsPhysical and deployment acceptance
Network and trustFlows and client policyFirewall, DNS, PKI, and monitoring
State and logsInventory and redaction behaviorClassification, retention, and disposal
ResponseSupport and rollback procedureIncident owner and escalation

Section 07

Pilot and evidence requirements

A local pilot should answer whether intended employees use the terminal, whether it performs reliably, and whether it changes the named workflow under accepted controls.

Require a written charter, baseline, target and placement record, measurement definitions, issue log, success criteria, stop conditions, and post-pilot decision. Do not accept a projected financial output as evidence of operating effect.

Claims must be labeled measured, modeled, example, assumption, or customer-provided. Ask what was measured directly, what was calculated, what conditions changed, and whether the result can be reproduced from documented inputs.

Pilot acceptance record

EvidenceRequired contentAccepted by
BaselineDates, users, definitions, exceptions________
Technical testNormal, failure, recovery, removal________
UsageSessions, failures, support events________
Workflow effectMovement and named transitions________
DecisionExpand, revise, extend, or remove________

Section 08

Commercial, legal, and support review

Evaluate the complete operating commitment: scope, included services, acceptance, billing terms, support, changes, warranties, data obligations, termination, and removal.

Confirm whether quantities and locations can change, how additional devices are approved, what implementation and support are included, how service levels are defined, and what happens at termination. Align contract language with the accepted architecture and the dealership's actual deployment configuration.

Do not allow economic claims to bypass the evidence standard. Financial review should reproduce from named inputs, show break-even assumptions, and state that recovered time creates potential capacity rather than guaranteed sold labor.

Commercial and legal record

Scope, quantities, locations, and acceptance
Term, billing, renewal, and termination
Implementation, support, updates, and incident contacts
Data handling, confidentiality, retention, and disposal
Warranties, limitations, insurance, and responsibility boundaries

Section 09

Weighted evaluation scorecard

Assign weights before final demonstrations and require a note for every score. The example weights below total 100 but should be adjusted by the buying organization.

A high score should reflect evidence, not presentation quality. Record gating failures separately; a weighted total should not override a failed security, legal, safety, or operational requirement.

Final decision: approve / conditional approval / pilot / revise / decline. Decision owner: ____________________ Date: __________

Vendor scorecard

CategoryExample weightScore 1-5Evidence / note
Business and workflow fit20____________________
User and role fit10____________________
Architecture and data handling20____________________
Security and network controls20____________________
Pilot evidence15____________________
Lifecycle and support10____________________
Commercial and legal fit5____________________

Weighted result = sum(weight × score) ÷ 5. Record all gating failures outside the total.

Questions this document helps answer

What should an initial review establish?

Confirm the operating problem, intended users, approved existing sessions, connection model, endpoint controls, evidence plan, and removal process.

Which claims need evidence?

Treat outcomes as measured only when supported by repository or dealership evidence; label projections, examples, assumptions, and customer-provided inputs.

Does procurement replace a pilot?

No. Procurement can define requirements and controls, while a pilot tests local adoption, reliability, placement, and workflow effect.

Use the scorecard during operational and technical review

Use the evidence, worksheets, and decision questions in this document with verified dealership inputs and the appropriate operational and technical owners.