SaaS-based driver full life cycle management method and device
By adopting a SaaS-based driver lifecycle management approach, driver identity information is collected and verified, and status data is statistically analyzed and monitored. This solves the problem of driver lifecycle management in a single-tenant system, achieves data isolation and anomaly alerts, and ensures the continuity and effectiveness of management.
Patent Information
- Application Number
- CN202510983632.2
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-07-16
- Publication Date
- 2025-11-28
AI Technical Summary
The single-tenant system of ride-hailing platforms makes it difficult to manage drivers throughout their entire lifecycle, resulting in the inability to share driver data across tenants and hindering effective lifecycle management.
A SaaS-based driver lifecycle management approach is adopted, which collects and verifies driver identity information, statistically analyzes status data based on candidate stages, detects abnormal information, and uses a multi-tenant mechanism for data isolation to achieve full lifecycle management of drivers.
It enables data preparation and status analysis for the entire driver lifecycle, provides abnormal information alerts throughout the lifecycle, and ensures data isolation and continuity of management.
Smart Images

Figure CN121032518A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of cloud computing technology, and more specifically to a SaaS-based method and apparatus for driver lifecycle management. Background Technology
[0002] In related technologies, the single-tenant system of ride-hailing platforms has difficulty in managing the entire lifecycle of drivers. Therefore, managing the entire lifecycle of drivers has become an urgent problem to be solved. Summary of the Invention
[0003] In view of this, the present invention provides a SaaS-based driver lifecycle management method and device to solve the problem of difficulty in achieving full lifecycle management of ride-hailing drivers in related technologies.
[0004] In a first aspect, the present invention provides a SaaS-based method for managing the entire lifecycle of drivers, the method comprising:
[0005] Collect and verify the driver's identity information;
[0006] Based on the candidate stage the driver is in, the corresponding status data for the candidate stage is statistically analyzed. The candidate stage includes the entire lifecycle of the driver from registering an account on the SaaS platform to canceling the account.
[0007] Based on status data and identity information, abnormal information of drivers throughout their entire lifecycle is detected and alerts are issued.
[0008] In one optional implementation, collecting and verifying the driver's identity information includes:
[0009] Obtain the driver's license information and / or completed information;
[0010] Verify the validity of document information through pre-set verification interfaces of transportation and / or government departments;
[0011] Verify that the driver's identity matches the information on their identification document. If so, use the identification document information as the driver's identity information.
[0012] In one optional implementation, based on the candidate stage the driver is in, the corresponding state data for the candidate stage is statistically analyzed, including:
[0013] During the candidate phase, which is within the preset time for starting account registration, the progress of the driver completing the registration according to the instructions is recorded, and the status data is marked as the registration status.
[0014] When the candidate stage is the account pending review stage, record the current review progress and mark the status data as the review status;
[0015] When the candidate stage is the driver's normal operating stage, record the driver's physical condition, number of orders received, and get off work attendance, and mark the status data as the operating status.
[0016] When the candidate stage is the driver sleep stage, record the sleep duration set by the driver and mark the status data as sleep state.
[0017] In one optional implementation, based on status data and identity information, abnormal information of the driver throughout the entire lifecycle is detected and alerts are issued, including:
[0018] If the status data indicates that the business is operating, the system verifies whether the identity information has expired based on its validity period. If the identity information has expired, the system reminds the driver to reissue the corresponding documents and re-enters the information for the reissued documents.
[0019] In one optional implementation, based on status data and identity information, detecting and alerting to abnormal information of the driver throughout the entire lifecycle further includes:
[0020] If the status data indicates a dormant state and the dormant duration exceeds the dormant threshold, the driver will be prompted to reactivate their account.
[0021] In an optional implementation, the method further includes:
[0022] The multi-tenancy mechanism on the SaaS platform isolates status data from drivers.
[0023] Secondly, the present invention provides a SaaS-based driver lifecycle management device, the device comprising:
[0024] The data collection module is used to collect and verify the driver's identity information;
[0025] The statistics module is used to collect status data corresponding to the candidate stage based on the driver's current candidate stage. The candidate stage includes the entire lifecycle of the driver from registering an account on the SaaS platform to canceling the account.
[0026] The detection module is used to detect abnormal information about the driver based on status data and identity information and to issue alerts.
[0027] Thirdly, the present invention provides a computer device, comprising: a memory and a processor, the memory and the processor being communicatively connected to each other, the memory storing computer instructions, and the processor executing the computer instructions to perform the SaaS-based driver lifecycle management method described in the first aspect or any corresponding embodiment thereof.
[0028] Fourthly, the present invention provides a computer-readable storage medium storing computer instructions for causing a computer to execute the SaaS-based driver lifecycle management method described in the first aspect or any corresponding embodiment thereof.
[0029] Fifthly, the present invention provides a computer program product, including computer instructions for causing a computer to execute the SaaS-based driver lifecycle management method described in the first aspect or any corresponding embodiment thereof.
[0030] The SaaS-based driver lifecycle management method provided by this invention achieves the following beneficial technical effects compared to existing technologies:
[0031] By collecting and verifying driver identity information, the starting point for driver lifecycle management is confirmed. Based on the candidate stage the driver is in, status data corresponding to that stage is statistically analyzed. The candidate stage includes the driver's entire lifecycle from account registration on the SaaS platform to account cancellation. This provides data preparation for driver lifecycle status analysis. Based on the status data and identity information, abnormal information about the driver throughout the lifecycle is detected and alerts are issued. Different information is fed back according to different lifecycle nodes, thus achieving full lifecycle management of the driver. Attached Figure Description
[0032] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.
[0033] Figure 1 This is a flowchart of a SaaS-based driver lifecycle management method according to an embodiment of the present invention;
[0034] Figure 2 This is a flowchart of the multi-tenant isolation processing according to an embodiment of the present invention;
[0035] Figure 3 This is a schematic diagram of a driver lifecycle management system architecture according to an embodiment of the present invention;
[0036] Figure 4 This is a schematic diagram of driver lifecycle state transition according to an embodiment of the present invention;
[0037] Figure 5This is a structural block diagram of a SaaS-based driver lifecycle management device according to an embodiment of the present invention;
[0038] Figure 6 This is a schematic diagram of the hardware structure of a computer device according to an embodiment of the present invention. Detailed Implementation
[0039] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.
[0040] First, some concepts involved in this invention will be explained as follows:
[0041] Software as a Service (SaaS) is a cloud-based software delivery model where users subscribe to and use application software deployed on cloud servers via the internet, without having to purchase, install, or maintain hardware and software infrastructure themselves.
[0042] The SaaS-based driver lifecycle management approach can be applied to the digital management of ride-hailing driver resources by ride-hailing platform operators.
[0043] In related technologies, single-tenant systems of ride-hailing platforms require independent deployment of servers and databases. When new tenants or partners appear, redeployment is necessary, and driver data cannot be shared across tenants, making it difficult to manage drivers throughout their entire lifecycle.
[0044] According to an embodiment of the present invention, a driver lifecycle management method based on SaaS is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.
[0045] This embodiment provides a SaaS-based driver lifecycle management method, which can be used on a server. Figure 1 This is a flowchart of a SaaS-based driver lifecycle management method according to an embodiment of the present invention, such as... Figure 1 As shown, the process includes the following steps:
[0046] Step S101: Collect and verify the driver's identity information.
[0047] In this embodiment, the identity information includes, but is not limited to, driver information recorded on ID cards, driver's licenses, and vehicle registration certificates. The driver's identity information is collected, and the documents are verified by the corresponding document verification agency.
[0048] Step S102: Based on the candidate stage the driver is in, statistically analyze the status data corresponding to the candidate stage. The candidate stage includes the entire lifecycle of the driver from registering an account on the SaaS platform to canceling the account.
[0049] In this embodiment, the candidate stage refers to the different periods throughout the driver's lifecycle on the SaaS-based ride-hailing platform, from registering an account to canceling it. The status data consists of driver data collected by the server at different candidate stages. Based on the driver's current candidate stage, the driver's status data for that stage is statistically analyzed.
[0050] Step S103: Based on status data and identity information, detect abnormal information of the driver throughout the entire lifecycle and issue a reminder.
[0051] In this embodiment, based on the driver's status data and identity information at different candidate stages, abnormal information of the driver throughout the entire life cycle is detected and the driver is alerted.
[0052] This embodiment provides a SaaS-based driver lifecycle management method that collects and verifies driver identity information to confirm the starting point of driver lifecycle management. Based on the candidate stage the driver is in, the method statistically analyzes the corresponding status data for that stage. The candidate stage includes the driver's entire lifecycle from account registration on the SaaS platform to account cancellation, obtaining driver status data at different lifecycle stages and providing data preparation for driver lifecycle status analysis. Based on the status data and the identity information, the method detects and alerts the driver regarding any abnormal information throughout the lifecycle, providing different information based on different lifecycle nodes, thus achieving full lifecycle management of the driver.
[0053] In some optional implementations, step S101 above includes the following steps:
[0054] Step S1011: Obtain the driver's document information and / or the information already filled in.
[0055] In this embodiment, the document information includes, but is not limited to, information recorded on ID cards, driver's licenses, and vehicle registration certificates. The information already filled in refers to the information already filled in by the driver in the ride-hailing software on the terminal device. The server obtains the document information uploaded by the driver, or the server obtains the information already filled in by the driver in the ride-hailing software, or the server obtains both the document information uploaded by the driver and the information already filled in by the driver in the ride-hailing software. For example, the driver's documents can be identified using optical character recognition capabilities provided by a third-party cloud service provider, automatically identifying and collecting the document information.
[0056] Step S1012 verifies the validity of the document information through a preset verification interface of the transportation and / or government departments.
[0057] In this embodiment, the verification interface refers to the verification service provided by transportation and / or government departments for specific document information, which can verify the authenticity and validity of the document information. The validity of the document information is verified through a pre-defined verification interface provided by transportation and / or government departments.
[0058] In one example of this embodiment, the validity of the driver's license and vehicle registration certificate is verified using the traffic management department's driver's license and vehicle registration certificate verification service. In another possible example, the mandatory motor vehicle traffic accident liability insurance verification service is used to verify the driver's mandatory liability insurance.
[0059] Step S1013: Verify whether the driver's identity matches the document information. If so, use the document information as the identity information.
[0060] In this embodiment, after obtaining the driver's identification information, the results of facial recognition or liveness detection are compared with the identification information to confirm whether the person and the identification match. If the person and the identification match, the identified identification information is used as the driver's identity information.
[0061] The technical solution of this implementation method completes the collection and verification of driver identity information, providing a prerequisite for the management of drivers throughout their entire life cycle.
[0062] In some optional implementations, step S102 above includes the following steps:
[0063] Step S1021: When the candidate stage is within the preset time for starting account registration, record the progress of the driver completing the registration according to the instructions, and mark the status data as the registration status.
[0064] In this embodiment, if the driver's current candidate stage is within a preset timeframe for registering an account on the ride-hailing platform, then the driver's progress in completing the registration according to the registration instructions is recorded, and the driver's status data is marked as registered. For example, within 30 minutes of starting account registration in the ride-hailing software, the status data is marked as registered.
[0065] Step S1022: When the candidate stage is the account pending review stage, record the current review progress and mark the status data as the review status.
[0066] In this embodiment, if the driver is currently in the candidate stage, which is the stage after registering on the ride-hailing platform and waiting for approval (i.e., the pending approval stage), then the status data will be marked as the approval status.
[0067] Step S1023: When the candidate stage is the driver's normal operating stage, record the driver's physical condition, number of orders received, and get off work attendance, and mark the status data as operating status.
[0068] In this embodiment, if the driver is currently in a candidate stage where they have completed registration, passed the review, and are now accepting orders and operating normally, the driver's physical condition, number of orders received, and commuting schedule are recorded during this stage. For example, the driver's emotions and fatigue can be identified through in-vehicle cameras, or the driver's physical condition can be identified through wearable devices and uploaded to the ride-hailing platform's server. The driver's status data at this stage is then identified as the operating status.
[0069] Step S1024: When the candidate stage is the driver sleep stage, record the sleep duration set by the driver and mark the status data as sleep state.
[0070] In this embodiment, if the driver is currently in a dormant phase where they are not accepting orders, the dormant duration set by the driver is recorded. For example, if the driver sets a 10-day dormant period, then the driver's status data is identified as dormant.
[0071] The technical solution of this embodiment records the status data of ride-hailing drivers at each stage of their entire lifecycle on the ride-hailing platform, and divides the driver's lifecycle into multiple stages of status data, which helps to manage the driver's entire lifecycle.
[0072] In some optional implementations, step S103 above includes the following steps:
[0073] If the status data indicates that the business is operating, the system verifies whether the identity information has expired based on its validity period. If the identity information has expired, the system reminds the driver to reissue the corresponding documents and re-enters the information for the reissued documents.
[0074] In this embodiment, if the driver's status data indicates an "operating" status, the system verifies whether the driver's identity information has expired based on its validity period. If the identity information has expired, the driver is reminded to renew the corresponding identification document, and the information on the renewed document is re-entered into the ride-hailing platform. This provides a reminder for abnormal document validity periods in an "operating" status. For example, if the driver's ID card has expired, the system reminds the driver to update it.
[0075] In some optional implementations, step S103 above further includes the following steps:
[0076] If the status data indicates a dormant state and the dormant duration exceeds the dormant threshold, the driver will be prompted to reactivate their account.
[0077] In this embodiment, if a driver's status data shows a dormant state and the dormancy duration exceeds a preset dormancy threshold, it indicates that the driver has not been operating for an extended period. The driver is then prompted to reactivate their account and return to operational status. This allows for lifecycle management of dormant drivers.
[0078] In some alternative implementations, the SaaS-based driver lifecycle management approach also includes:
[0079] The multi-tenancy mechanism on the SaaS platform isolates status data from drivers.
[0080] In one example of this embodiment, the multi-tenant mechanism based on the SaaS platform isolates the status data from the driver, isolates the tenant data from the tenant data, and inputs the service parameters when using the SaaS platform service. These input parameters carry tenant information to ensure data isolation.
[0081] Figure 2 This is a flowchart illustrating the multi-tenant isolation processing of an embodiment of the present invention. Figure 2As shown, in the full lifecycle management of a SaaS-based ride-hailing platform, the basis for isolation is the use of a unique tenant identifier, such as a tenant ID, to initiate operation requests for driver data during API calls or user actions. The operation request is sent to the gateway via Hypertext Transfer Protocol (HTTP), which checks for the existence of a tenant identifier. If the identifier is missing, the process terminates with an exception message, and access is denied. If the identifier exists, the operation request is forwarded to the corresponding backend system service. Within the system service, services handling driver lifecycle business logic (such as driver service and order service) receive the request. Before performing any operation (such as querying, updating, or deleting driver information or status), the service enforces the use of the tenant identifier carried in the request as a filtering condition. At the database layer, the database tables must contain a tenant identifier field, and all query, update, and delete operations explicitly include tenant identifier conditions at the SQL level. Business data (such as driver name, status, license plate, rating, contract, etc.) is stored together with the tenant identifier, ensuring physical isolation.
[0082] Figure 3 This is a schematic diagram of a driver lifecycle management system architecture according to an embodiment of the present invention. Figure 3 As shown, starting from the gateway layer, which serves as the unified access point (corresponding to the OpenAPI gateway described in the text), it is responsible for request routing and protocol adaptation. The business layer includes four key microservices: data collection service, driver attendance record service, driver information service, and driver status management service. The data collection service collects driver identification information, information filled in on the ride-hailing platform, and driver facial recognition and other identity verification information, supporting real-name authentication such as Optical Character Recognition (OCR) / liveness detection. The driver information service is used to implement CRUD operations on driver information. The driver status management service maintains account and identification status. The driver attendance record service is the core module, used to manage driver attendance and dispatch.
[0083] These services collectively cover the entire driver lifecycle—from information entry or collection, daily commute operations, status tracking to data maintenance—forming a closed-loop management system. While the driver data early warning module is not explicitly marked in the diagram, as a business-layer big data analytics capability, it can leverage data from other services for real-time monitoring and risk alerts.
[0084] The business layer connects to the data layer, employing a multi-engine coexistence strategy to adapt to different scenarios: MySQL, as a relational database, stores highly consistent structured data such as driver information and status records; ClickHouse handles high-concurrency time-series data (such as drivers' daily commute records) and supports rapid aggregation and analysis; HBase carries semi-structured or unstructured data (such as OCR-recognized images and raw logs from the warning module), meeting the elastic expansion needs of massive data volumes. This design not only isolates the data pressure from different business processes (such as data queries and commute record writing) but also optimizes performance and cost through heterogeneous storage, providing robust data support for each business module.
[0085] Figure 4 This is a schematic diagram illustrating the driver lifecycle state transition according to an embodiment of the present invention. Figure 4 As shown, the SaaS platform's full lifecycle management of ride-hailing drivers begins with account registration. After registering for the first time, drivers enter a status of either submitting funds or awaiting review. At this point, they need to submit materials and wait for manual or system review. After approval, drivers need to complete the "activation" process by logging into the system again to set their account password, thus activating their identity. Once activated, drivers enter a normal state and can officially begin business operations: maintaining personal information, clocking in and out, receiving and responding to orders, entering a normalized operational phase.
[0086] When a driver needs to suspend service due to temporary absence (such as vacation or document renewal), they enter a "dormant" state, during which they cannot accept orders but their data is retained. If a driver decides to permanently leave the platform or is removed due to violations, the "cancellation" process is triggered, the account and associated data are removed, and the account's lifecycle ends. This design satisfies the tenant's (ride-hailing company) need for dynamic management of driver resources while ensuring business continuity through state isolation—for example, dormant drivers can be quickly restarted, while cancelled drivers need to re-register, ensuring the integrity and security of driver data in a multi-tenant environment.
[0087] This embodiment also provides a SaaS-based driver lifecycle management device, which is used to implement the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" can be a combination of software and / or hardware that implements a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.
[0088] This embodiment provides a SaaS-based driver lifecycle management device, such as... Figure 5 As shown, it includes:
[0089] The data collection module 501 is used to collect and verify the driver's identity information;
[0090] The statistics module 502 is used to collect status data corresponding to the candidate stage based on the candidate stage in which the driver is located. The candidate stage includes the entire lifecycle of the driver from registering an account on the SaaS platform to canceling the account.
[0091] The detection module 503 is used to detect abnormal information of the driver based on status data and identity information and to issue a warning.
[0092] In some alternative implementations, the acquisition module 501 includes:
[0093] The acquisition unit is used to acquire the driver's document information and / or the information already filled in;
[0094] The document verification unit is used to verify the validity of document information through a preset verification interface of transportation and / or government departments;
[0095] The identity verification unit is used to verify whether the driver's identity matches the information on the document. If so, the document information is used as the identity information.
[0096] In some alternative implementations, the statistics module 502 includes:
[0097] The first statistical unit is used to record the progress of drivers completing registration according to the instructions within a preset time period when the candidate stage is the start of account registration, and to mark the status data as the registration status.
[0098] The second statistical unit is used to record the current review progress and mark the status data as the review status when the candidate stage is the account pending review stage;
[0099] The third statistical unit is used to record the driver's physical condition, number of orders received, and get off work attendance when the candidate stage is the driver's normal operating stage, and to mark the status data as the operating status.
[0100] The fourth statistical unit is used to record the sleep duration set by the driver when the candidate stage is the driver sleep stage, and to identify the status data as sleep state.
[0101] In some alternative implementations, the detection module 503 includes:
[0102] The identity verification unit is used to verify whether the identity information has expired if the status data is "operating". If the identity information has expired, the driver is reminded to reissue the corresponding document and the reissued document information is re-entered.
[0103] In some alternative implementations, the detection module 503 further includes:
[0104] The reminder unit is used to remind the driver to reactivate the account if the status data is in a dormant state and the dormant duration exceeds the dormant threshold.
[0105] In some alternative implementations, the method further includes:
[0106] The isolation module is used to isolate status data from drivers in the multi-tenant mechanism of the SaaS platform.
[0107] Further functional descriptions of the above modules and units are the same as those in the corresponding embodiments described above, and will not be repeated here.
[0108] In this embodiment, the SaaS-based driver lifecycle management device is presented in the form of functional units. Here, a unit refers to an application-specific integrated circuit (ASIC) circuit, a processor and memory that execute one or more software or fixed programs, and / or other devices that can provide the above functions.
[0109] This invention also provides a computer device having the above-described features. Figure 6 The device shown is a SaaS-based driver lifecycle management system.
[0110] Please see Figure 6 , Figure 6 This is a schematic diagram of the structure of a computer device provided in an optional embodiment of the present invention, such as... Figure 6 As shown, the computer device includes one or more processors 10, memory 20, and interfaces for connecting the components, including high-speed interfaces and low-speed interfaces. The components communicate with each other via different buses and can be mounted on a common motherboard or otherwise installed as needed. The processors can process instructions executed within the computer device, including instructions stored in or on memory to display graphical information of a GUI on external input / output devices (such as display devices coupled to the interfaces). In some alternative implementations, multiple processors and / or multiple buses can be used with multiple memories and multiple memory modules, if desired. Similarly, multiple computer devices can be connected, each providing some of the necessary operations (e.g., as a server array, a group of blade servers, or a multiprocessor system). Figure 6 Take a processor 10 as an example.
[0111] Processor 10 may be a central processing unit, a network processor, or a combination thereof. Processor 10 may further include a hardware chip. The hardware chip may be an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. The programmable logic device may be a complex programmable logic device (CAMP), a field-programmable gate array (FPGA), a general-purpose array logic (GPA), or any combination thereof.
[0112] The memory 20 stores instructions executable by at least one processor 10 to cause at least one processor 10 to perform the method shown in the above embodiments.
[0113] The memory 20 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on the use of the computer device. Furthermore, the memory 20 may include high-speed random access memory and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some alternative embodiments, the memory 20 may optionally include memory remotely located relative to the processor 10, and these remote memories may be connected to the computer device via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.
[0114] The memory 20 may include volatile memory, such as random access memory; the memory may also include non-volatile memory, such as flash memory, hard disk or solid-state drive; the memory 20 may also include a combination of the above types of memory.
[0115] The computer device also includes a communication interface 30 for communicating with other devices or communication networks.
[0116] This invention also provides a computer-readable storage medium. The methods described above according to embodiments of the invention can be implemented in hardware or firmware, or implemented as computer code that can be recorded on a storage medium, or implemented as computer code downloaded via a network and originally stored on a remote storage medium or a non-transitory machine-readable storage medium and then stored on a local storage medium. Thus, the methods described herein can be processed by software stored on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. The storage medium can be a magnetic disk, optical disk, read-only memory, random access memory, flash memory, hard disk, or solid-state drive, etc.; further, the storage medium can also include combinations of the above types of memory. It is understood that computers, processors, microprocessor controllers, or programmable hardware include storage components capable of storing or receiving software or computer code, which, when accessed and executed by the computer, processor, or hardware, implements the methods shown in the above embodiments.
[0117] A portion of this invention can be applied as a computer program product, such as computer program instructions, which, when executed by a computer, can invoke or provide the methods and / or technical solutions according to the invention through the operation of the computer. Those skilled in the art will understand that the forms in which computer program instructions exist in a computer-readable medium include, but are not limited to, source files, executable files, installation package files, etc. Correspondingly, the ways in which computer program instructions are executed by a computer include, but are not limited to: the computer directly executing the instructions, or the computer compiling the instructions and then executing the corresponding compiled program, or the computer reading and executing the instructions, or the computer reading and installing the instructions and then executing the corresponding installed program. Here, the computer-readable medium can be any available computer-readable storage medium or communication medium accessible to a computer.
[0118] Although embodiments of the invention have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of the invention, and all such modifications and variations fall within the scope defined by the appended claims.
Claims
1. A SaaS-based method for managing the entire lifecycle of drivers, characterized in that, The method includes: Collect and verify the driver's identity information; Based on the candidate stage the driver is in, the status data corresponding to the candidate stage is statistically analyzed, wherein the candidate stage includes the entire lifecycle of the driver from registering an account on the SaaS platform to canceling the account; Based on the status data and the identity information, abnormal information of the driver throughout the entire life cycle is detected and an alert is issued.
2. The method according to claim 1, characterized in that, The collection and verification of the driver's identity information includes: Obtain the driver's identification information and / or completed information; The validity of the document information is verified through a pre-defined verification interface of the transportation and / or government departments. Verify whether the driver's identity matches the document information. If so, use the document information as the identity information.
3. The method according to claim 1, characterized in that, The step of statistically analyzing the state data corresponding to the candidate stage based on the driver's current candidate stage includes: When the candidate stage is within the preset time for starting account registration, record the progress of the driver completing the registration according to the instructions, and mark the status data as the registration status; When the candidate stage is the account pending review stage, the current review progress is recorded as the status data, and the status data is marked as the review status; When the candidate stage is the driver's normal operating stage, the driver's physical condition, number of orders received, and get off work attendance are recorded, and the status data is marked as operating status. When the candidate stage is the driver sleep stage, the sleep duration set by the driver is recorded, and the status data is identified as sleep state.
4. The method according to claim 3, characterized in that, The step of detecting and alerting the driver regarding abnormal information throughout the entire lifecycle based on the status data and the identity information includes: If the status data indicates the business status, the driver is reminded to renew the identity information based on its validity period. If the identity information has expired, the driver is then reminded to renew the document corresponding to the identity information and to re-enter the information of the renewed document.
5. The method according to claim 3, characterized in that, The method of detecting and alerting the driver regarding abnormal information throughout the entire lifecycle based on the status data and the identity information further includes: If the status data indicates a dormant state and the dormant duration exceeds the dormant threshold, the driver is prompted to reactivate their account.
6. The method according to any one of claims 1-5, characterized in that, The method further includes: The multi-tenancy mechanism of the SaaS platform isolates the status data from the driver.
7. A SaaS-based driver lifecycle management device, characterized in that, The device includes: The data collection module is used to collect and verify the driver's identity information; The statistics module is used to collect status data corresponding to the candidate stage based on the candidate stage in which the driver is located. The candidate stage includes the entire lifecycle of the driver from registering an account on the SaaS platform to canceling the account. The detection module is used to detect abnormal information of the driver based on the status data and the identity information, and to issue a warning.
8. A computer device, characterized in that, include: A memory and a processor are interconnected, the memory stores computer instructions, and the processor executes the SaaS-based driver lifecycle management method according to any one of claims 1 to 6 by executing the computer instructions.
9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions for causing the computer to execute the SaaS-based driver lifecycle management method as described in any one of claims 1 to 6.
10. A computer program product, characterized in that, Includes computer instructions for causing a computer to execute the SaaS-based driver lifecycle management method as described in any one of claims 1 to 6.