MoviGestion: Automating Fleet Management for Personnel Transport Companies Using a Conversational System and IoT Powered by AI

Abstract

The increasing complexity of fleet operations often forces drivers and administrators to alternate between fragmented tools for geolocation, messaging, and spreadsheet-based reporting, which slows response times and increases cognitive load. This study evaluates a comprehensive architectural framework designed to automate fleet management in personnel transport companies. The research proposes a unified methodology integrating Internet-of-Things (IoT) telemetry, cloud analytics, and Conversational AI to mitigate information fragmentation. Through a Lean UX iterative process, the proposed system was modeled and validated, with 30 participants (10 administrators and 20 drivers) who performed representative operational tasks in a simulated environment. Usability was assessed through the System Usability Scale (SUS), obtaining a score of 71.5 out of 100, classified as “Good Usability”. The results demonstrate that combining conversational interfaces with centralized operational data reduces friction, accelerates decision-making, and improves the overall user experience in fleet management contexts.

1. Introduction

Fleet management has become a growing economic and logistical challenge worldwide. The global market for fleet management solutions was valued at USD 28.6 billion in 2023 and is projected to reach USD 55.6 billion by 2028, with a compound annual growth rate of 14.2% [1]. The transportation of goods and people represents more than 10% of the GDP of many developed and emerging economies, demanding increasingly efficient and intelligent fleet management systems [2]. Similar trends are reported by Farahpoor et al. [3], who highlight the importance of integrating Industrial IoT architectures for operational efficiency. While more than 30 million vehicles in North America are connected to professional platforms, Latin America only reaches 6.5 million, with projections to double this figure by 2028.

In the Latin American context, the high level of urbanization has intensified transportation demand, while AI-driven logistics solutions have proven capable of reducing delivery times by up to 22% [4]. However, this growth has also led to congestion, increased CO₂ emissions, and greater operational complexity [5]. In Peru, Lima alone operates approximately 32,000 formal buses, but 84% of operators still rely on informal channels such as WhatsApp to assign routes, report incidents, and communicate operational updates [6]. The coexistence of personal and work-related messages in the same medium fragment’s information, delays responses, and compromises service reliability—generating higher costs and user dissatisfaction.

These inefficiencies directly affect profitability and service quality. Reports by Berg Insight (2024) indicate that routing problems and the lack of automated reporting can increase operating costs by up to 20%. A Logistics 4.0 meta-analysis corroborates comparable cost overruns across multiple sectors [7]. Improving these processes not only reduces expenses but also increases customer satisfaction and contributes to environmental sustainability through optimized fuel consumption.

Several recent studies—from digital twins for operations and maintenance [8] to predictive maintenance models based on artificial intelligence [9]—show that inadequate route planning and poor decision management can increase fleet expenses by 15–25%. In Peruvian personnel transportation, where high vehicle density and complex urban geography are common, these inefficiencies negatively affect both fuel consumption and service punctuality.

Despite advances in IoT-based fleet management, a literature review reveals that most existing platforms focus on telemetry collection and route visualization but rarely incorporate conversational interfaces that contextualize real-time operational data for managers and drivers. Recent reviews of large language models (LLMs) in intelligent transportation confirm that chatbot-based assistants can enhance decision support in connected fleets [10]. However, commercial applications remain focused on web dashboards, neglecting the conversational layer and forcing users to switch between separate systems (tracking software, instant messaging, spreadsheets). This fragmentation leads to delayed decisions and dispersed data.

To address these challenges, the primary objective of this research is to design and validate a computational model that integrates Natural Language Processing (via Dialogflow CX) with real-time IoT telemetry. Rather than solely developing a software product, this study aims to demonstrate how conversational agents can effectively bridge the gap between raw technical data and human decision-making in fleet operations.

The proposed architecture, described in Section 3, includes: (i) Spring Boot Monolith on Azure App Service; (ii) an IoT Hub for collecting and synchronizing telemetry from each vehicle; (iii) an AI-based conversational agent to deliver context-aware alerts and recommendations; and (iv) an intuitive mobile interface developed in Flutter that promotes accessibility and technology adoption.

As a pilot limitation, the system depends on 4G connectivity; therefore, data are stored locally and synchronized once the signal is restored. Future versions plan to incorporate low-cost satellite links to extend coverage in rural areas.

Research Questions and Hypotheses To guide this investigation and address the identified gaps in fragmented fleet management, this study poses the following Research Questions (RQ):

RQ1: How does the integration of a conversational interface (chatbot) with real-time IoT telemetry affect the efficiency of incident reporting and operational decision-making in personnel transport fleets?

RQ2: To what extent can a unified, user-centered mobile platform reduce administrative workload and improve perceived usability for non-technical drivers compared to traditional manual coordination?

Consistent with the Lean UX approach detailed in Section 3, this research posits the following central Hypotheses (H):

H1: The centralization of operational tasks through a natural-language chatbot coupled with IoT data significantly reduces incident response time (IRT) compared to fragmented channels (e.g., WhatsApp and spreadsheets).

H2: A unified interface that contextualizes technical telemetry into conversational alerts improves route accuracy and user satisfaction (usability) for field operators.

Finally, continuous evaluation based on user feedback ensures that the system remains adaptable and scalable for its future application across different private transportation companies. The following sections describe the related work (Section 2), the methodology based on the Lean UX approach (Section 3), the experimental validation (Section 4), and the discussion and conclusions (Section 5 and Section 6).

2. Related Work

This section reviews recent contributions in the field of intelligent fleet management and connected transportation systems. The literature was analyzed along four main axes: (i) Internet-of-Things (IoT) platforms and end-to-end architectures for data ingestion and analytics; (ii) data-driven governance and decision-support frameworks for fleet strategy; (iii) advanced models for predictive maintenance, digital twins, and spatiotemporal forecasting; and (iv) the emerging use of Large Language Models (LLMs) for conversational, optimization, and control tasks in intelligent transportation.

Table 1 summarizes the most relevant approaches and positions the contribution of MoviGestion within this research landscape.

2.1. IoT Platforms and Data Analytics in Fleet Management

Recent research has established robust foundations for fleet management through IoT and data analytics, though gaps remain in user interaction. Farahpoor et al. [3] proposed an end-to-end IoT system for industrial fleets that integrates data acquisition and cloud-based analytics. While their architecture demonstrates high technical integration, it lacks a human–machine interaction layer and does not include validation with end users. Similarly, Punith et al. [11] developed an IoT prototype for vehicle tracking that validates the feasibility of connectivity but does not assess usability or integrate natural-language orchestration to reduce operator workload. Focusing on the strategic level, Pozueco et al. [12] emphasized analytics-based governance and dashboards to improve cost efficiency; however, their proposal does not incorporate conversational automation or real-time coupling with sensor data to trigger operational workflows. MoviGestion addresses these specific gaps by embedding conversational access to telemetry directly within a mobile interface and validating the system through user experience metrics.

2.2. Advanced Predictive Models and Optimization Systems

Significant progress has been made in using advanced computational models for transport operations and maintenance. Werbińska-Wojciechowska et al. [8] reviewed the application of digital twins, noting that while they provide high-fidelity simulation, they demand substantial infrastructure and expertise that limit adoption by smaller enterprises; MoviGestion offers a more lightweight and accessible architecture for similar monitoring objectives. In the realm of fault diagnosis, Chaudhuri and Ghosh [9] proposed hybrid deep-learning ensembles that achieve superior accuracy in industrial IoT environments but require extensive labeled datasets and lack a mechanism to operationalize predictions for human actors. MoviGestion bridges this “last-mile” gap by transforming system alerts into actionable conversational feedback. Furthermore, recent advances have combined LLM reasoning with reinforcement learning (RL) to optimize traffic flow [13], outperforming classical baselines at a macroscopic network level. However, these systems often lack a direct interface for fleet operators. MoviGestion translates this type of intelligence to the micro-operational level, integrating IoT telemetry with natural-language coordination validated through usability testing.

2.3. Emerging Applications of LLMs and Edge Intelligence in Transportation

The integration of Large Language Models (LLMs) and edge computing represents a frontier in intelligent transportation research. Huang and Deng [14] introduced a multi-agent LLM framework for railway surveillance using edge stream processing, while Rong et al. [15] presented a spatiotemporal generative model for vehicular-flow prediction in 6G environments. Both studies demonstrate the power of distributed intelligence for security and forecasting but lack direct user interaction mechanisms. In the cybersecurity domain, Aishwarya et al. [16] proposed a unified intrusion-detection model that leverages LLMs to normalize heterogeneous vehicular data—an architectural principle echoed in MoviGestion’s integration of IoT signals. Furthermore, Abraham et al. [17] provided a forward-looking review of GenAI applications for electric vehicle routing and user communication. However, much of this work remains prospective or focused on macro-level network tasks. MoviGestion builds upon this vision by grounding conversational and IoT integration in an implemented, usability-tested prototype that addresses micro-operational execution.

Summary and Differentiation

Table 1 summarizes the comparative analysis of these representative studies. While prior research has predominantly focused on either technical infrastructure (IoT, analytics) or specific predictive tasks (security, traffic forecasting), few works address end-to-end user interaction validated through standard metrics. MoviGestion differentiates itself by integrating a conversational agent with real-time IoT telemetry and validating its effectiveness specifically through the System Usability Scale (SUS).

Table 1. Summary comparison with related works.

Work	Main Contribution	Differentiation
Farahpoor (2023) [3]	End-to-end IoT architecture for industrial fleets.	Lacks conversational interface; no user validation.
Punith (2022) [11]	Data analytics and governance for fleet strategy.	No conversational or real-time operational coupling.
Pozueco (2023) [12]	IoT prototype for monitoring and events.	No usability evaluation or natural-language task orchestration.
Werbińska (2024) [8]	Digital twins for transport operation and maintenance.	High cost and complexity; limited accessibility.
Chaudhuri (2024) [9]	Deep-learning ensembles for predictive maintenance.	Requires large datasets; lacks human-in-loop interaction.
Rong (2024) [15]	LLM + edge computing for spatiotemporal traffic prediction.	Macro-scale focus; no conversational or IoT task integration.
Huang (2025) [14]	Multi-agent LLM + edge stream processing for railway tracking.	Security domain; no conversational fleet interface.
Aishwarya (2025) [16]	Unified LLM-based IDS for IoV with high accuracy.	Focus on cybersecurity; lacks operational orchestration.
Abraham (2025) [17]	Vision of LLM/GenAI for ITS in the EV era.	Conceptual; no empirical validation or usability metrics.
Alrashed (2025) [13]	LLM + RL for real-time traffic optimization.	Urban-scale optimization; no fleet-level conversational control.
This work	Integration of chatbot + IoT for executing fleet tasks with SUS validation.	User-validated prototype integrating conversational UX and IoT telemetry for fleet operations

Table 1. Summary comparison with related works.

Work	Main Contribution	Differentiation
Farahpoor (2023) [3]	End-to-end IoT architecture for industrial fleets.	Lacks conversational interface; no user validation.
Punith (2022) [11]	Data analytics and governance for fleet strategy.	No conversational or real-time operational coupling.
Pozueco (2023) [12]	IoT prototype for monitoring and events.	No usability evaluation or natural-language task orchestration.
Werbińska (2024) [8]	Digital twins for transport operation and maintenance.	High cost and complexity; limited accessibility.
Chaudhuri (2024) [9]	Deep-learning ensembles for predictive maintenance.	Requires large datasets; lacks human-in-loop interaction.
Rong (2024) [15]	LLM + edge computing for spatiotemporal traffic prediction.	Macro-scale focus; no conversational or IoT task integration.
Huang (2025) [14]	Multi-agent LLM + edge stream processing for railway tracking.	Security domain; no conversational fleet interface.
Aishwarya (2025) [16]	Unified LLM-based IDS for IoV with high accuracy.	Focus on cybersecurity; lacks operational orchestration.
Abraham (2025) [17]	Vision of LLM/GenAI for ITS in the EV era.	Conceptual; no empirical validation or usability metrics.
Alrashed (2025) [13]	LLM + RL for real-time traffic optimization.	Urban-scale optimization; no fleet-level conversational control.
This work	Integration of chatbot + IoT for executing fleet tasks with SUS validation.	User-validated prototype integrating conversational UX and IoT telemetry for fleet operations

3. Methodology

This section describes the methodological approach used to design, structure, and verify the MoviGestion solution under the Lean UX cycle—Think, Make, and Check. In brief, the Think stage frames the problem and elicits user needs to derive testable UX hypotheses; the Make stage materializes those hypotheses through physical and logical architectures documented with C4 views (Context, Containers, Components, and Code) and interactive prototypes; and the Check stage defines the usability verification strategy using Nielsen’s heuristics and the System Usability Scale (SUS) as the primary instrument. The overall process emphasizes traceability from user insight to architectural decisions and evaluation criteria, following good practices in software architecture description and human–computer interaction.

3.1. Think Phase: Discovery and Hypotheses

The Think phase aimed to understand the operational context of personnel transportation, the actors involved, and the pain points that hinder efficient fleet coordination. This early discovery focused on framing the problem space, eliciting user needs, and formulating testable UX hypotheses aligned with technical feasibility and usability.

Problem framing and contextual inquiry: An exploratory inquiry with fleet administrators and drivers revealed heavy reliance on fragmented communication (e.g., instant messaging for task assignment and incident reporting), which disperses information, delays responses, and reduces traceability. Field observations indicated that a large share of route assignments is handled manually without structured feedback or live status, reinforcing the need for a centralized channel coupled with operational data.

Empathy and stakeholder understanding: Semi-structured interviews and on-site observations (administrators n = 2; drivers n = 4; see Appendix A) highlighted recurrent issues: delayed notifications, repetitive messaging, manual incident tracking, and high cognitive load when switching between apps and spreadsheets. From these insights, two primary personas were modeled—administrator and driver—emphasizing requirements such as clarity of tasks, simplicity of interaction, and offline resilience in the field.

This initial sample size (n = 6) was intentionally restricted to the discovery phase (‘Think’) to facilitate in-depth qualitative analysis and empathy mapping, where data saturation regarding user pain points is typically reached within the first six to twelve interviews [18]. In contrast, the subsequent validation phase (‘Check’) expanded the cohort to 30 participants to ensure statistical relevance for the quantitative usability assessment.

Assumptions and UX hypotheses: Based on the discovery, we articulated assumptions about behavior and environment and paired them with falsifiable UX hypotheses to guide design decisions and validation in later stages (Make and Check).

Example rows:

• Assumption: Communication is fragmented across channels. Hypothesis: If we centralize incident reporting and route updates in one interface, response latency will decrease.
• Assumption: Drivers need immediate, minimal-effort reporting. Hypothesis: If we enable natural-language reporting, the time to log incidents will drop and data completeness will increase.
• Assumption: Administrators manage multiple routes concurrently. Hypothesis: If we surface route state and exceptions at a glance, prioritization will improve.

Backlog preparation: The hypotheses were translated into a prioritized product backlog (e.g., incident reporting via conversational interface, route state overview, IoT telemetry integration, alerts and notifications). This backlog guided the subsequent Make phase, where architecture and prototypes were produced for early validation.

3.2. Make Phase: Architecture and Prototyping

In the Make phase of Lean UX, the solution is materialized through physical and logical architectures and exercised with interactive prototypes. The physical architecture specifies the deployment and distribution of software and hardware elements across the technology infrastructure (devices, runtimes, integration points), while the logical architecture organizes responsibilities, domains, and interactions at the design level. Addressing both perspectives provides traceability from design intent to runtime behavior and supports modifiability, scalability, and reliability in operational contexts [19,20].

To structure and communicate design decisions, we adopt the C4 model—Context, Containers, Components, and Code—which offers layered views that improve shared understanding among stakeholders and alignment between design and engineering teams [21]. In practice, we present: (i) a Context view to define scope and actors; (ii) Containers to map runtime responsibilities; (iii) Components to decompose services and modules; and (iv) an indicative Code view (classes/interfaces) to clarify how abstractions are realized.

Design ideas and UX hypotheses from the product backlog were converted into interactive prototypes, enabling rapid feedback on layout, navigation, and task completion before full implementation. These prototypes—first as wireframes and later as high-fidelity mockups—helped validate content hierarchy, interaction affordances, and visual consistency under realistic constraints (mobile screens, connectivity, and on-field usage) [22].

3.3. Check Phase: Validation Strategy

The Check stage defines the strategy to assess whether the proposed design works as intended and delivers value to users before full implementation. We adopt a mixed approach that combines structured observation and standardized questionnaires to evaluate perceived functionality, usability, and areas for improvement.

A core reference for interactive systems is Nielsen’s usability heuristics, which emphasize principles such as visibility of system status, match between the system and the real world, consistency and standards, and error prevention. These principles guide both design and evaluation, helping identify friction points, prevent user errors, and improve acceptance of the system [23,24].

For quantitative measurement, we rely on the System Usability Scale (SUS), a ten-item Likert questionnaire developed by John Brooke (1986) that provides a single score in the 0–100 range [25]. The SUS is widely used due to its brevity, robustness, and comparability across digital systems, and its benchmarks are commonly used to guide iterative design decisions [26,27]. The SUS items used in this study are listed below.

(All numerical results and analyses derived from the SUS are reported in Section 4.3.)

4. Results

We followed the Lean UX approach described in Section 3 (Methodology), structured into the three stages: Think, Make, and Check.

In the Think stage, user research tools such as empathy mapping, UX hypothesis statements, and a prioritized product backlog were employed to identify and understand user needs in the fleet management context.

The Make stage involved the materialization of these hypotheses into a coherent system architecture and interactive prototypes that allowed early validation of the solution design.

Finally, the Check stage focused on validating the user experience and system usability through quantitative and qualitative methods, specifically using the System Usability Scale (SUS) and feedback interviews with fleet administrators and drivers.

Each stage contributed valuable insights to ensure that MoviGestion effectively addresses operational pain points, enhances communication between administrators and drivers, and delivers an intuitive, efficient, and satisfactory user experience.

4.1. Think Phase Outcomes

Empathy map (outputs): To ensure a user-centered design, we synthesized the discovery insights into an empathy map for the two primary profiles—fleet administrators and drivers. The artifact consolidates what each profile sees, hears, thinks/feels, and does in their daily workflow, highlighting pain points and desired outcomes. Administrators reported friction from dispersed communication channels (e.g., messaging apps and spreadsheets) and limited traceability of operations, while drivers emphasized delays and uncertainty in route updates and overhead when reporting incidents during field operations. These findings are summarized in the empathy maps for drivers and administrators, Figure 1 and Figure 2.

Assumptions and UX hypotheses (evidence for design): From the empathy map and contextual inquiry, the resulting matrix of assumptions and falsifiable UX hypotheses is presented in

Table 2. Assumptions and UX Hypotheses for MoviGestion.

N°	Assumption (Operational Context)	UX Hypothesis	Intended Effect/Observable Metric
1	Communication is fragmented across channels (chat apps, spreadsheets) reducing traceability and slowing response.	If we centralize routing, incident reporting and status in a single interface (chatbot + app), then response latency and missed events will decrease.	Median time from incident → acknowledgment; % incidents with complete fields; # duplicated/lost messages.
2	Drivers need immediate, low-effort reporting while on route.	If we enable natural-language incident reporting, then time to log an incident will drop and data completeness will increase.	Task time (report incident); % reports with required evidence; error rate in category selection.
3	Administrators juggle multiple routes concurrently and need quick prioritization.	If we surface route state and exceptions at a glance, then prioritization accuracy and switch cost will improve.	# context switches/hour; % correct prioritizations in scenario tests; time to open critical route card.
4	Lack of real-time operational data leads to uncertainty in decisions.	If we integrate IoT telemetry (GPS/temp/humidity) with the conversational flow, then on-time decisions will increase and manual checks will drop.	% on-time reassignments; # manual location requests; time from anomaly → action.
5	Connectivity is intermittent in field operations.	If we provide offline capture with local caching and background sync, then task completion will remain stable under low connectivity.	Completion rate with/without network; sync success rate; conflict rate after reconnection.
6	Cognitive load rises when modules are not well integrated.	If we ensure strong functional integration and consistent flows, then perceived usability will improve.	SUS Item 5 (“functions well integrated”) and global SUS; # navigation detours.
7	Critical events require timely, proactive notification.	If we implement real-time push notifications for exceptions, then acknowledgment and resolution times will decrease.	Time alert → first view; time alert → status change; % alerts acknowledged within SLA.
8	Dense technical information hinders decision-making in motion.	If we apply hierarchical information, concise copy, and progressive disclosure, then errors and rereads will decrease.	Error rate on parameter checks; # rereads per screen; NASA-TLX (effort) delta in A/B tests.
9	Evidence (photos, notes) is scattered, delaying audits.	If we bind multimedia evidence to each incident/route event, then audit time will shrink and satisfaction will increase.	Avg. time to assemble an incident record; % incidents with photo/log; admin CSAT on traceability.
10	New users must be productive quickly with minimal training.	If we keep flows consistent with platform conventions and provide in-flow hints, then time-to-first-task and errors will drop.	Time-to-first-successful route action; # help taps; SUS Items 3/7 (ease/learnability).

. We formalized assumptions and paired them with falsifiable UX hypotheses to guide design decisions and subsequent validation. The resulting matrix captures the link between an operational problem and a testable improvement target (e.g., response time, data completeness, or error rate).

These hypotheses operationalize the discovery insights and define measurable targets for validation in later stages, as detailed in Table 2.

Backlog derived from hypotheses (prioritization): The hypotheses were translated into a prioritized product backlog focusing on features that directly reduce coordination friction and improve operational response.

Priority items include: conversational incident reporting, route state overview with exceptions, IoT telemetry integration for vehicle status, and alerts/notifications for time-critical events. The backlog items, their estimated value and acceptance criteria are shown in

Table 3. Product Backlog for MoviGestion.

Code	User Story/Title	Value (1/2/3/5/8)	Hypothesis Link	Acceptance Criteria (Summary)
US001	As a driver, I want to report an incident via chatbot (NL) so that I can log events with minimal effort while on route.	8	H2, H6	User can submit incident with type, location, optional photo; confirmation shown; record stored and visible to admin within ≤10 s.
US002	As an admin, I want a route state overview with exceptions so that I can prioritize actions quickly.	8	H3	Dashboard lists all routes with real-time status; exceptions (delay/deviation) highlighted; open a route in ≤2 clicks.
US003	As an operator, I want IoT telemetry integration (GPS/temp/humidity) so that decisions use live data.	8	H4	Telemetry received ≥1/min per vehicle; last update timestamp visible; map position and sensor values consistent with device feed.
US004	As an admin/driver, I want real-time alerts/notifications for critical events so that I can act immediately.	8	H7	Push triggered on deviation/overheat/stop > threshold; alert contains link to entity; ack recorded with timestamp.
US005	As a driver, I want offline capture with background sync so that I can work under poor connectivity.	5	H5	Actions (incident, checklist) work without network; queue syncs automatically; conflict strategy defined and tested.
US006	As an admin, I want integrated evidence (photos/notes) bound to each incident so that audits are faster.	5	H3	Add/view/delete evidence per incident; metadata (who/when) stored; download from admin panel.
US007	As an admin, I want KPI dashboards (incidents/time, on-time %, MTTR) so that I can monitor performance.	5	H9	KPIs render for selected period/route; export CSV/PDF; latency ≤3 s for last 30 days.
US008	As a driver, I want guided copy and progressive disclosure so that the UI is easy to understand in motion.	5	H1, H3	Forms show only necessary fields; helper texts and inline validation; no dead-ends; back action preserves input.
US009	As an admin, I want geofencing & deviation detection so that I can manage route compliance.	5	H8, H10	Create/edit polygons/waypoints; deviation rule configurable; events logged and visible on timeline/map.
US010	As an admin, I want role-based access (admin/driver) so that data is protected and tasks are scoped.	3	H3, H4	AuthN/AuthZ with roles; drivers see own routes/incidents only; admins manage all entities.
US011	As an admin, I want maintenance/vehicle records unified with operations so that decisions have context.	3	H4	CRUD for vehicles and maintenance logs; link incident ↔ vehicle; history visible per unit.
US012	As a user, I want voice/read-out prompts for stops so that I can reduce screen attention while driving.	2	H4, H9	Optional TTS for stop arrival; toggle per user; respects do-not-disturb mode and platform guidelines.

.

This prioritization ties each user story to its originating hypothesis to ensure traceability across design and validation.

4.2. Make Phase Implementation

Based on the hypotheses and the prioritized product backlog from Section 4.1, the Make stage materialized the solution through a cohesive technical architecture and interactive prototypes aimed at early usability evaluation.

4.2.1. Architecture (C4 Views)

Context (C1): MoviGestion operates as a centralized hub connecting three actors: drivers (incident reporting and route assignments), administrators (monitoring and decision-making), and IoT devices (GPS/ Speedometer telemetry).

External services support the workflow: Google Maps APIs for geocoding/visualization, Dialogflow CX for natural-language interaction, and Azure IoT Hub for real-time telemetry ingestion. The overall scope and actors are summarized in the context view Figure 3.

Containers (C2): The Flutter mobile client communicates with a Spring Boot backend deployed on Azure App Service. The backend integrates:

• IoT telemetry via Azure IoT Hub;
• Operational and user data in Azure SQL Database;
• Multimedia evidence in Azure Blob Storage; and

Push notifications through Firebase Cloud Messaging for time-critical events.

This setup ensures real-time communication, data consistency, and fault tolerance across components. The main runtime building blocks and their responsibilities are shown in the container view Figure 4.

Physical deployment: In the production environment, the backend is deployed on Azure App Service, operating as a RESTful API secured with HTTPS and JSON protocols. The mobile application, developed in Flutter/Dart, runs on Android devices (version 8 or higher) and integrates a local SQLite database for offline data persistence. Telemetry and incident data are transmitted via the IoT communication channel to the Azure SQL Database, ensuring data consistency, redundancy, and secure synchronization across all system components. Google Maps API handles real-time route visualization and geolocation services, while the Dialogflow-based Chatbot manages automated responses and communication with drivers and administrators. This deployment topology and its interaction layers are illustrated in Figure 5, representing the complete production-level implementation architecture of MoviGestión.

At the container level, the Flutter mobile app interacts with Dialogflow CX for NL intents and with a Spring Boot backend on Azure App Service; telemetry flows through Azure IoT Hub to Azure SQL while media is persisted in Blob Storage, and FCM delivers push alerts. Component-wise, dialog orchestration and rule evaluation are handled by Dialogflow CX and rule managers, while session controllers secure flows for both roles; the telemetry/alerts path integrates with Azure Functions and SQL. A consolidated end-to-end pipeline illustrating mobile, dialog, telemetry, storage, and notification paths is provided in Figure 6, while a rule-oriented variant highlighting session control and business-rule managers is shown in Figure 7 for completeness.

4.2.2. Prototypes

Visual prototypes and interaction: Prototypes were iteratively built in Figma and implemented in Flutter (Material Design 3), emphasizing task clarity, low visual load, and offline resilience. The login and dashboard prioritize quick navigation and visibility of active routes and exceptions, while profile and incident-report views keep critical actions one tap away, as shown in Figure 8.

Conversational interface: The chatbot enables drivers to report incidents, request route updates, and consult vehicle information using natural language; administrators monitor these interactions within a centralized dashboard enriched with IoT telemetry for immediate context, see Figure 9.

Summary of the Make stage: This stage consolidated the tangible structure of MoviGestion, integrating conversational AI, IoT telemetry, and a modular architecture into a unified system. The layered C4 views provide conceptual clarity and reproducibility, while the prototypes enabled early checks on layout and interaction prior to the verification activities reported in Section 4.3 (Check).

4.2.3. Conversational Agent Configuration and Training

To ensure accurate natural language understanding (NLU) in the specific context of Peruvian personnel transport, the Dialogflow CX agent was trained using a supervised dataset derived from the ‘Think’ phase interviews. We defined 12 custom intents covering core operational tasks (e.g., Report_Incident, Query_Route_Status, Check_Vehicle_Maintenance), as shown in Figure 10, and 5 custom entities for extracting parameters such as location names, incident types (mechanical vs. traffic), and timeframes. The training corpus consisted of approximately 80 training phrases, including local slang and variations in phrasing common among drivers; specific examples of this configuration are illustrated in Figure 11. The agent utilizes a deterministic state machine for flow control, ensuring that critical reports (like accidents) trigger an immediate escalation flow, while informational queries follow a standard retrieval flow connected to the Azure SQL Database via Webhooks.

4.3. Check Phase Validation

The Check stage evaluated perceived usability and the effectiveness of the MoviGestion prototype using the System Usability Scale (SUS). Thirty participants (n = 30; administrators n = 10, drivers n = 20) interacted with the application under simulated operational conditions representative of fleet operations.

4.3.1. Experimental Setup and Field Deployment

The evaluation was conducted in a real-world operational setting involving 20 active buses and 10 administrators from the partner company. Unlike purely lab-based simulations, this study performed “in situ” testing: drivers utilized the MoviGestion application on Android devices via 4G cellular networks while operating their actual assigned routes in Lima.

To assess the system’s response without disrupting passenger safety, we employed a “simulated injection” protocol: specific operational triggers (e.g., a “simulated engine failure” or “simulated route deviation”) were introduced at planned intervals. This allowed us to measure the system’s technical latency (IoT telemetry propagation) and the users’ reaction times (Incident Response Time) under realistic noise, vibration, and connectivity conditions typical of the field.

Technological environment:

• Backend: Spring Boot monolithic API on Azure App Service with Azure SQL Database.
• IoT layer: Azure IoT Hub ingesting GPS, Speedometer telemetry
• Conversational layer: Dialogflow CX; notifications via Firebase Cloud Messaging.
• Mobile client: Flutter 3.22 (Android ≥ 8) with SQLite for offline tolerance.

Participants and tasks.

Administrators managed routes and monitored vehicles; drivers executed assigned routes and reported incidents. After performing these core operational tasks (route creation/tracking, incident reporting via chatbot, technical/maintenance queries), all participants completed the SUS and an open-ended feedback prompt.

4.3.2. Instrumentation: System Usability Scale (SUS)

The System Usability Scale (SUS) comprises 10 statements rated on a 5-point Likert scale. Positively worded items are recoded as (response—1) and negatively worded items as (5—response); the total is then multiplied by 2.5 to yield a 0–100 overall score, as illustrated in Figure 12.

For interpretation, we adopt widely used bands: ≥80 indicates excellent usability, 68–79 good, 50–67 marginal, and <50 poor usability.

4.3.3. Quantitative Results

The average SUS was 71.5 ± 14.0 (range 47.5–100), which falls within Good Usability and exceeds the commonly applied 68-point acceptability threshold reported in the literature [23]. Item 5 (perceived functional integration) and Item 7 (learnability) showed higher agreement (means 4.17 and 3.93, respectively), while items reflecting complexity or cumbersomeness displayed low disagreement, supporting an overall intuitive experience, as summarized in

Table 4. Mean and Contribution of Each SUS Item.

Item	Statement (Summary)	Type	Average (n = 30)	SUS Contribution	Item
1	I think I would use MoviGestion frequently.	+	3.93	2.93	1
2	I find MoviGestion more complicated than necessary.	−	1.97	3.03	2
3	I find MoviGestion easy to use.	+	3.77	2.77	3
4	I feel I would need technical assistance to use all of MoviGestion’s features.	−	2.63	2.37	4
5	MoviGestion’s features work smoothly together.	+	4.17	3.17	5
6	I find too many inconsistencies or confusing steps when using MoviGestion.	−	1.93	3.07	6
7	I think most people would learn how to use MoviGestion quickly.	+	3.93	2.93	7
8	I found MoviGestion cumbersome to use.	−	1.9	3.1	8
9	I feel confident using MoviGestion.	+	3.87	2.87	9
10	I had to learn many new things before I could use MoviGestion correctly.	−	2.63	2.37	10
	Gross sum		28.61
Overall SUS				71.5

. In addition, the study context is illustrated with field images of the validation sessions—administrator and driver perspectives—see Figure 13, Figure 14 and Figure 15.

4.3.4. Qualitative Results

In open-ended responses, participants emphasized clear route visualization, centralized technical/maintenance data, and fluent chatbot interactions for reporting and queries. Suggested improvements included offline operation, voice guidance, and automatic delay alerts, which inform the next iteration under a Lean UX cycle, as detailed in

Table 5. Thematic Synthesis of Qualitative Feedback.

Qualitative Observations from the Complementary Open-Ended Questions	Qualitative Observations from the Complementary Open-Ended Questions
Perceived usefulness	The map helps me avoid getting lost. The map guides me well, and I do not get lost.
Data centralization	Having everything in one place makes my work easier. I like that all vehicle technical information is centralized; I can view maintenance history, location, and alerts in a single place.
Chatbot and routes	It is easy to know which route is assigned to me and at what time. I like seeing the status of each route in real time.
Suggested improvements	Announce stops by voice so I do not have to look at the screen. Send a notification if a bus is running late. Provide alerts if a bus remains stationary for an extended period. A voice alert upon arrival at each stop would be helpful. An offline mode that works without internet access would be useful. Add a dedicated report for fuel expenditure.

.

Summary

The validation indicates that MoviGestion achieves Good Usability (SUS = 71.5 ± 14.0), with strengths in feature integration and learnability (Table 4). Qualitative evidence supports the design direction and highlights concrete enhancements (offline operation, voice/alerts) (Table 5). Together, the results substantiate the hypotheses derived in Think and the design decisions implemented in Make, and set the scope for subsequent pilots in real operational conditions Figure 13, Figure 14 and Figure 15.

4.3.5. Exploratory Operational Impact (Simulated)

Design and setting. We conducted a before–after comparison in a simulated operational environment with 20 drivers and 10 administrators, mirroring representative fleet conditions. Two non-overlapping windows were analyzed: a pre-intervention period (manual coordination via messaging apps and spreadsheets) and a post-intervention period using MoviGestion (chatbot + IoT telemetry + push notifications). Events were time-stamped (UTC−05) and stored in a sandbox database. Daily aggregates were computed and then summarized at the window level.

KPIs and computation.

• Incident response time (IRT, min): Time from incident creation (driver) to first acknowledgment (admin). We used the daily median IRT (robust to skew) and averaged across days.

$${\mathrm{P}\mathrm{e}\mathrm{r}\mathrm{c}\mathrm{e}\mathrm{n}\mathrm{t} \mathrm{c}\mathrm{h}\mathrm{a}\mathrm{n}\mathrm{g}\mathrm{e}:(\mathrm{I}\mathrm{R}\mathrm{T}}_{\mathrm{B}\mathrm{e}\mathrm{f}\mathrm{o}\mathrm{r}\mathrm{e}}-{\mathrm{I}\mathrm{R}\mathrm{T}}_{\mathrm{A}\mathrm{f}\mathrm{t}\mathrm{e}\mathrm{r}}) /{\mathrm{I}\mathrm{R}\mathrm{T}}_{\mathrm{B}\mathrm{e}\mathrm{f}\mathrm{o}\mathrm{r}\mathrm{e}}\times 100\mathrm{\%}$$

• Route 100 m of the waypoint and the absolute time difference |Δt| ≤ 3 min between planned and observed pass; computed per day and averaged across routes.

$${\mathrm{P}\mathrm{e}\mathrm{r}\mathrm{c}\mathrm{e}\mathrm{n}\mathrm{t} \mathrm{c}\mathrm{h}\mathrm{a}\mathrm{n}\mathrm{g}\mathrm{e}:(\mathrm{R}\mathrm{A}}_{\mathrm{A}\mathrm{f}\mathrm{t}\mathrm{e}\mathrm{r}}-{\mathrm{R}\mathrm{A}}_{\mathrm{B}\mathrm{e}\mathrm{f}\mathrm{o}\mathrm{r}\mathrm{e}}) /{\mathrm{R}\mathrm{A}}_{\mathrm{B}\mathrm{e}\mathrm{f}\mathrm{o}\mathrm{r}\mathrm{e}}\times 100\mathrm{\%}$$

• Administrative workload (AW, events/day): Manual coordination volume (messages, calls, ad hoc sheet edits) linked to incidents and routing. Percent change as for IRT.

Data quality controls. Implausible GPS jumps (>300 m/s) were discarded. Days with data completeness <90% for the required signals were excluded from window averages.

Results (simulated). Compared to the period prior to the intervention, the MoviGestion window shows a 35% reduction in IRT, a 20% improvement in RA, and a decrease in AW in line with centralized coordination. The comparison at the grouped view level of the three KPIs is shown in Figure 16; the daily trajectories of RA, IRT, and AW are provided in Figure 17, Figure 18 and Figure 19, respectively.

The data presented in Figure 16, Figure 17, Figure 18 and Figure 19 were extracted from the system’s sandbox SQL database, which logged all time-stamped interactions and telemetry events generated during the 14-day simulated operation window described in the Experimental Setup.

Interpretation and limitations. These exploratory estimates suggest that conversational coordination coupled with integrated IoT telemetry can accelerate acknowledgment of field incidents, improve adherence to planned routes, and reduce administrative overhead. However, the results derive from simulation and remain sensitive to Δt/Δd tolerances, scenario design, and sample size; hence, they should be interpreted as indicative rather than definitive pending validation in live operations.

5. Discussion

The System Usability Scale (SUS) result for MoviGestion was 71.5 ± 14.0, which places the prototype in the Good Usability band and above the widely used 68-point acceptability threshold established in the literature. This finding reinforces the suitability of a user-centred, Lean UX process (Think–Make–Check) as described in Section 3, where early hypotheses from discovery (Think) were materialized through architecture and prototypes (Make) and then verified with standard instruments (Check). In particular, high agreement on integration and learnability items indicates that the design choices around layout, information hierarchy, and consistent flows supported users’ mental models.

A key differentiator of MoviGestion is the tight integration of the conversational interface with IoT telemetry and cloud services, enabling a single operational channel for drivers and administrators. As reported in Section 4.3, participants emphasized that natural-language interaction simplified incident reporting and status queries while reducing fragmentation caused by ad hoc messaging. This aligns with established usability principles (e.g., visibility of system status, match with the real world, error prevention), suggesting that the chatbot-centred workflow can lower cognitive load during field tasks and increase user control in time-critical contexts.

Beyond perceived usability, the exploratory operational analysis conducted in a controlled simulation (Section 4.3.5) suggests promising effects on efficiency for a representative setting with 20 drivers (20 buses) and 10 administrators. Using pre-specified KPIs and before–after windows, MoviGestion was associated with a 35% reduction in incident response time, a 20% improvement in route accuracy, and a 25% decrease in administrative workload. While these are indicative rather than definitive estimates (see the data-quality controls and computation notes in Section 4.3.5), the direction and magnitude of change are consistent with the qualitative feedback and the SUS profile, pointing to a virtuous link between usability and operational performance.

Table 6. Summary of Hypothesis Validation and Key Empirical Findings.

Research Hypothesis	Indicator/Metric	Quantitative Result	Validation Outcome
H1: Conversational IoT centralization reduces Incident Response Time (IRT).	Incident Response Time (IRT) (min)	35% reduction (Median decreased vs. baseline)	Supported. The integration of chatbot alerts accelerated acknowledgment significantly.
H2: Unified interface improves Route Accuracy (RA) and User Satisfaction.	Route Accuracy (RA) (%)	20% improvement (Higher adherence to waypoints)	Supported. Real-time context helped drivers stay on route.
H2 (cont.): Usability and Acceptance.	System Usability Scale (SUS) (0–100)	Score: 71.5 ± 14.0 (“Good Usability”)	Supported. Score exceeds the 68-point industry benchmark.
Goal: Efficiency/Admin Workload.	Administrative Workload (AW) (events/day)	25% decrease (Fewer manual calls/msgs)	Supported. Automated logging reduced manual supervision needs.

summarizes how the empirical evidence obtained during the ‘Check’ phase supports the initial research hypotheses, linking specific quantitative gains to the proposed architectural improvements.

When contrasted with recent work in fleet/ITS domains, MoviGestion occupies a complementary space. Several studies emphasize algorithmic or architectural robustness (e.g., IoT ingestion, predictive models) but provide limited human-centred validation with end users. Our approach contributes by bridging operational intelligence and UX evidence, tailoring the interaction model to Latin-American field realities (intermittent connectivity, multitasking on-route, rapid acknowledgment needs), and documenting both perceptual (SUS) and operational (KPI) outcomes under a single methodological umbrella.

There are, however, limitations that bound interpretation. First, the SUS sample (n = 30) and the operational analysis window, although representative, remain modest; broader deployments across multiple companies and route typologies are needed to generalize effects. Second, network coverage occasionally impacted synchronization; despite offline caching, future versions should evaluate hybrid links (e.g., 5G/LPWAN) and adaptive sync policies for low-signal corridors. Third, the variance in SUS (σ = 14.0) hints at heterogeneous digital literacy—especially among drivers—suggesting room for enhanced onboarding, progressive disclosure, and voice-assisted prompts to support diverse user profiles.

Overall, the discussion indicates that MoviGestion achieves a balanced integration of conversational AI, IoT telemetry, and cloud analytics with accessible interaction design. The Lean UX cycle enabled rapid convergence from hypotheses to prototypes and evidence, and the combined SUS–KPI view provides a cohesive picture of user acceptance and potential operational gains. Future work should (i) extend real-world pilots with stratified routes and longer observation windows, (ii) incorporate multimodal interaction (voice commands/notifications) to minimize visual load in motion, and (iii) embed predictive analytics for proactive maintenance and route optimization. These steps aim to move usability from Good toward Excellent while consolidating MoviGestion as a scalable, human-centred platform for personnel transport operations.

6. Conclusions

This work presented MoviGestion, a human-centred fleet-management solution that integrates a conversational interface with IoT telemetry and cloud analytics. Guided by the Lean UX cycle (Think–Make–Check), discovery insights were translated into explicit assumptions and UX hypotheses, then materialized through a modular C4-based architecture and interactive prototypes before verification with end users.

From a usability standpoint, the prototype achieved a SUS score of 71.5 ± 14.0, placing it in the Good Usability band. Strengths were observed in feature integration and learnability, consistent with the design decisions on information hierarchy, consistent flows, and a single operational channel for drivers and administrators. Qualitative feedback emphasized clarity of route visualization, fluid chatbot interaction for reporting and queries, and the value of centralizing operational/technical data.

Beyond perception, an exploratory before–after analysis in simulation—reflecting a representative setting with 20 drivers (20 buses) and 10 administrators—suggested potential efficiency gains: −35% incident response time, +20% route accuracy, and −25% administrative workload. While indicative, these effects align with the SUS profile and user feedback and point to a positive link between usability and operational performance.

Overall, the results indicate that a single, conversational workflow enriched with IoT signals can reduce communication fragmentation, improve situational awareness, and support timely decisions in personnel transport contexts. The architecture’s modularity and interoperability (mobile app, Dialogflow CX, Azure IoT Hub/SQL/Functions, FCM, and maps services) provide a practical path to scale and adapt to heterogeneous field conditions.

Future work will extend pilots in real operational environments with longer observation windows and stratified route types; incorporate multimodal interaction (voice commands/notifications) to further reduce visual load in motion; and embed predictive analytics for proactive maintenance and route optimization. These steps aim to move usability from Good toward Excellent and to consolidate MoviGestion as a scalable, sustainable platform for Latin-American transport ecosystems.