A service request processing method and device, electronic equipment and storage medium

Abstract

The application provides a service request processing method and device, electronic equipment and storage medium. In response to the selection operation of the target service request item in the service menu interface by the applicant according to the IT office demand, a service request editing interface corresponding to the target service request is displayed to obtain multiple request contents of the service request edited by the applicant. According to the obtained multiple request contents, a service request work order corresponding to the target service request is created. When the service request work order corresponding to the target service request meets the execution condition, the service request work order corresponding to the target service request is decomposed to generate multiple request tasks based on the processing flow corresponding to the target service request, and each request task is sent to the corresponding execution party for processing. When the processing state of all request tasks is completed, it is confirmed that the service request work order corresponding to the target service request is completed, and the applicant is notified to verify to improve the processing speed of the service request.

Description

Technical Field

[0001] This application relates to the field of Internet technology, and more specifically, to a method, apparatus, electronic device, and storage medium for processing service requests. Background Technology

[0002] To provide a unified submission portal for managing the IT project lifecycle, the industry commonly uses platforms developed based on ITSM (IT Service Management). However, in daily operations, directly using an ITSM platform lacks the fine-grained management of the required content for each request. ITSM platforms do not differentiate between service request types; the forms submitted are standardized, but the content required for processing varies for each request. This necessitates further offline communication between operations and development, increasing IT service communication costs and reducing timeliness. Summary of the Invention

[0003] In view of this, the purpose of this application is to provide a service request processing method, apparatus, electronic device and storage medium, which provides different service request editing interfaces for different scenarios to provide the executor with more comprehensive and effective data, reduce offline communication costs and improve the processing speed of service requests.

[0004] Firstly, this application provides a method for processing service requests. The method includes responding to a requester's selection of a target service request item in a service menu interface based on IT office needs; displaying a service request editing interface corresponding to the target service request; the service menu interface displays multiple service request items corresponding to the service requests; the service request editing interface displays multiple service request option editing boxes to obtain multiple request contents of the service request edited by the requester; creating a service request work order corresponding to the target service request based on the obtained multiple request contents; determining whether the service request work order corresponding to the target service request meets the execution conditions; when the service request work order corresponding to the target service request meets the execution conditions, decomposing the service request work order corresponding to the target service request into multiple request tasks based on the processing flow corresponding to the target service request, and sending each request task to the corresponding executor for processing; obtaining the processing status of each request task sent by the executor; when the processing status of all request tasks is "completed," confirming that the service request work order corresponding to the target service request has been completed, and notifying the requester to verify.

[0005] Preferably, the form editing interface includes a form editing area, a control display area, and an attribute editing area. The control display area includes multiple functional control items. The attribute editing area is used to edit form attributes or control attributes. The form editing area is used to display the configured form. A corresponding service request editing interface is configured for each service request in the following ways: The form editing interface is displayed in response to the selection operation of the new form control in the form creation interface; the corresponding control configuration box is displayed in the form editing area in response to the drag operation of the functional control item in the control display area; the edit button, copy button, and delete button are displayed in the control configuration box in response to the selection operation of the control configuration box; the control attribute editing interface is displayed in the attribute editing area in response to the selection operation of the edit icon control displayed in the control configuration box, and the editing information for that functional control is obtained to generate a service request option editing box corresponding to a request content; multiple different service request option editing boxes form a form corresponding to a service request, which is then displayed in the service request editing interface.

[0006] Preferably, the following method is used to determine whether the service request work order corresponding to the target service request meets the execution conditions: obtain the verification result of the service request work order corresponding to the target service request from the executor; if the verification result of the service request work order corresponding to the target service request is passed, submit the service request work order corresponding to the target service request to the approval process to obtain the approval result of the service request work order corresponding to the target service request; if the approval result of the service request work order corresponding to the target service request is passed, it is determined that the service request work order corresponding to the target service request meets the execution conditions.

[0007] Preferably, the request task includes at least multiple service request items. The verification result of the service request work order corresponding to the target service request is obtained by the executor in the following ways: For each request task, the request task is sent to the corresponding executor for verification; the executor verifies whether each service request item of the request task is within the production management scope according to the verification logic corresponding to the task type of the request task; and verifies whether each service request item of the request task is within the request execution scope according to the verification logic corresponding to the task type of the request task; if all service request items of each request task are within the production management scope and also within the request execution scope, then the verification result of the service request work order corresponding to the target service request is determined to be passed.

[0008] Preferably, the approval chain consists of multiple approvers with different permission levels, arranged in ascending order of permission level. The approval result of the service request work order corresponding to the target service request is obtained in the following way: the service request work order corresponding to the target service request is forwarded to the first approver in the approval chain; if the first approver approves the service request work order, the service request work order is forwarded to the next approver; if the first approver disapproves the service request work order, the approval result of the request task service request work order corresponding to the target service request is determined to be disapproved; if all approvers approve the service request work order, the approval result of the request task service request work order corresponding to the target service request is determined to be approved.

[0009] Preferably, the approval chain is configured as follows: Based on the scope of permissions required for the office needs of the target service request, determine the corresponding multiple permission levels; for each permission level, select at least one approver from all approvers at that permission level to approve the service request work order corresponding to the target service request.

[0010] Preferably, each request task has a processing attribute, which includes automatic processing and manual processing. For each request task, the executor processes the received request task in the following ways: determining the processing attribute of the request task; if the processing attribute of the request task is automatic processing, then automatically processing the request task according to the preset processing rules, and changing the processing status of the request task to "processing"; when the automatic processing is completed, then changing the processing status of the request task to "completed"; if the processing attribute of the request task is manual processing, then sending the request task to the system of the corresponding processor, so that the processor can manually process the request task, and updating the processing status of the request task according to the processor's modification operation of the task status in the system.

[0011] Secondly, this application provides a service request processing apparatus, the apparatus comprising:

[0012] The response module is used to respond to the applicant's selection of the target service request item in the service menu interface according to the IT office needs. It displays the service request editing interface corresponding to the target service request. The service menu interface displays multiple service request items corresponding to multiple service requests, and the service request editing interface displays multiple service request option editing boxes to obtain multiple request contents of the service request edited by the applicant.

[0013] The creation module is used to create a service request ticket corresponding to the target service request based on the multiple request contents obtained;

[0014] The judgment module is used to determine whether the service request work order corresponding to the target service request meets the execution conditions.

[0015] The decomposition module is used to decompose the service request work order corresponding to the target service request into multiple request tasks based on the processing flow corresponding to the target service request when the execution conditions are met, and send each request task to the corresponding executor for processing.

[0016] The receiving module is used to obtain the processing status of each request task sent by the executor. When the processing status of all request tasks is "completed", it confirms that the service request work order corresponding to the target service request has been completed and notifies the applicant to verify it.

[0017] Thirdly, this application also provides an electronic device, including: a processor, a memory, and a bus, wherein the memory stores machine-readable instructions executable by the processor, and when the electronic device is running, the processor communicates with the memory via the bus, and when the machine-readable instructions are executed by the processor, the steps of the service request processing method described above are performed.

[0018] Fourthly, this application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, performs the steps of the service request processing method described above.

[0019] The service request processing method, apparatus, electronic device, and storage medium provided in this application respond to the applicant's selection of a target service request item in the service menu interface according to IT office needs. It displays a service request editing interface corresponding to the target service request. The service menu interface displays multiple service request items corresponding to the service requests, and the service request editing interface displays multiple service request option editing boxes to obtain multiple request contents of the service request edited by the applicant. Based on the obtained multiple request contents, it creates a service request work order corresponding to the target service request; it determines whether the service request work order corresponding to the target service request meets the execution conditions; when the service request work order corresponding to the target service request meets the execution conditions, it decomposes the service request work order corresponding to the target service request into multiple request tasks based on the processing flow corresponding to the target service request, and sends each request task to the corresponding executor for processing; it obtains the processing status of each request task sent by the executor; when the processing status of all request tasks is "completed," it confirms that the service request work order corresponding to the target service request has been completed and notifies the applicant for verification. By providing different service request editing interfaces for different scenarios, it provides the executor with more comprehensive and effective data, reduces offline communication costs, and improves the processing speed of service requests.

[0020] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0021] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0022] Figure 1 A flowchart illustrating a service request processing method provided in an embodiment of this application;

[0023] Figure 2 A schematic diagram of a service request editing interface provided in an embodiment of this application;

[0024] Figure 3 A flowchart for determining whether a service request work order meets the execution conditions is provided in an embodiment of this application;

[0025] Figure 4 A flowchart illustrating a service request interaction provided in an embodiment of this application;

[0026] Figure 5 A schematic diagram of the structure of a service request processing apparatus provided in an embodiment of this application;

[0027] Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0028] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. The components of the embodiments of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely represents selected embodiments of this application. Based on the embodiments of this application, every other embodiment obtained by those skilled in the art without inventive effort falls within the scope of protection of this application.

[0029] First, the applicable application scenarios for this application will be introduced. This application can be applied to the fine-grained management of service requests on ITSM platforms.

[0030] To provide a unified submission portal for managing the IT project lifecycle, the industry commonly uses platforms developed based on the ITSM methodology. In daily work, if you directly use an ITSM platform:

[0031] 1) ITSM cannot manage the required content of requests in a granular manner. ITSM does not differentiate between service request types; the forms filled out when submitting are uniform, but the content required for processing varies for each request. This necessitates further offline communication between operations and development, increasing the communication costs and timeliness of IT services.

[0032] 2) ITSM cannot validate user-submitted content. The information provided by users during submission may not conform to production or operational specifications, and cannot be changed after submission. This can lead to inconsistencies between user-submitted content and actual implementation, making subsequent traceability inconvenient and hindering the widespread adoption of standards.

[0033] 3) ITSM cannot automate implementation. After ITSM collects user requests, operations personnel need to manually implement them on the corresponding operations platform and then process the request form in ITSM. This is inconvenient for operations personnel to manage their operations work uniformly and requires switching between different platforms, increasing operations costs.

[0034] Based on this, embodiments of this application provide a service request processing method, apparatus, electronic device, and storage medium.

[0035] Please see Figure 1 , Figure 1 This is a flowchart illustrating a service request processing method provided in an embodiment of this application. Figure 1 As shown in the embodiments of this application, the method for processing service requests includes:

[0036] S101. In response to the applicant's selection of the target service request item in the service menu interface based on IT office needs, the service request editing interface corresponding to the target service request is displayed. The service menu interface displays multiple service request items corresponding to multiple service requests, and the service request editing interface displays multiple service request option editing boxes to obtain multiple request contents of the service request edited by the applicant.

[0037] The applicant here can be an employee. They can select the corresponding service request item in the SPlus platform's service menu interface, and the platform will then display the corresponding service request editing interface. Each service request displays a different form in its editing interface, and SPlus uses a low-code approach to set different fields for each form, enabling rapid generation of compliant form content. This low-code approach also supports scenarios where forms need to be modified promptly due to changes in specifications or business needs, without requiring a system code release; operations and management personnel can update the configuration as needed.

[0038] In one embodiment of this application, the service menu interface includes several major categories such as IP telephony, office computers, onboarding / offboarding / transfer services, application software, remote office, office cloud storage, office network, account services, and email services. IP telephony includes service request items such as office IP phone number application and office IP phone / special function activation. Office computers include service request items such as terminal timed startup exception application, computer screensaver push application, and temporary screen watermark removal application. Office network includes service request items such as fixed IP address application, internet blacklist website blocking application, and IP address query (data collection) application.

[0039] Each service request here has a pre-set corresponding form, and the applicant simply needs to fill in the corresponding information.

[0040] For example, when the target service request is a regular operating system software installation, the corresponding service request editing interface is as follows: Figure 2 As shown. The title, reporter, and commitment invalidation fields are mandatory edit boxes for every service request. The operation type, system type, software name, host list, whether to auto-start, and supplementary description are configured based on the request content required for regular software installation on the operating system, helping the executor obtain the complete request content. An approval chain is also required for every service request. Understandably, the form displayed in the service request editing interface is different for each service request, allowing you to set optional fields, prompts, data sources, etc.

[0041] S102. Based on the obtained multiple request contents, create a service request work order corresponding to the target service request.

[0042] In this step, the applicant enters the corresponding information in the service request editing interface and clicks submit. The platform then creates a service ticket based on each request item edited by the applicant.

[0043] S103. Determine whether the service request work order corresponding to the target service request meets the execution conditions.

[0044] Please see Figure 3, Figure 3 This application provides a flowchart for determining whether a service request work order meets the execution conditions. Specifically, the process for determining whether a service request work order corresponding to a target service request meets the execution conditions is as follows:

[0045] S1030. Obtain the verification result of the service request work order corresponding to the target service request from the executor;

[0046] S1032. If the verification result of the service request work order corresponding to the target service request is passed, the service request work order corresponding to the target service request will be submitted to the approval process to obtain the approval result of the service request work order corresponding to the target service request.

[0047] S1034. If the approval result of the service request work order corresponding to the target service request is passed, then it is determined that the service request work order corresponding to the target service request meets the execution conditions.

[0048] Each work order requires approval from authorized personnel and data verification from the corresponding implementing party to ensure that the data in the work order conforms to management and domain standards and has been authorized by leadership or relevant management personnel. However, the existing ITSM only provides a general description of the request in a single "Details" field, without specifying which information is required or verifying that mandatory fields are selected.

[0049] It's important to note that each service request has its own independent validation logic. The validation logic differs for different request content items, and the submitted request content must comply with both production management standards and domain-specific standards. For example, "Request to activate production VPN" will verify whether the applicant has already registered for a VPN and is within the production VPN whitelist; "Application resource offline" allows selecting some nodes to be offline, but not all active nodes, to prevent applicants from achieving the effect of overall offline status by submitting multiple partial node offline requests.

[0050] Specifically, the request task includes at least multiple service request items, and the verification result of the service request ticket corresponding to the target service request is obtained by the executor in the following way:

[0051] For each request task, it is sent to the corresponding executor for verification. The executor verifies, according to the verification logic corresponding to the task type, whether each service request item of the request task is within the production management scope. It also verifies, according to the verification logic corresponding to the task type, whether each service request item of the request task is within the request execution scope. If all service request items of each request task are both within the production management scope and within the request execution scope, then the verification result of the service request work order corresponding to the target service request is determined to be passed.

[0052] Here, a verification interface can be configured so that each service request ticket submission enters the verification node. Only after successful verification can it proceed to the approval node; otherwise, a reason for failure will be returned, and the applicant can then modify the information accordingly. When the specifications are adjusted, only the domain needs to modify the corresponding verification interface logic; SPlus remains unchanged.

[0053] S104. When the service request work order corresponding to the target service request meets the execution conditions, the service request work order corresponding to the target service request is decomposed into multiple request tasks based on the processing flow corresponding to the target service request, and each request task is sent to the corresponding executor for processing.

[0054] In this step, Ant breaks down each service request ticket according to a pre-defined processing flow and sends the resulting different request tasks to various domain systems (i.e., executors). These domain systems can be IT systems, bastion host management systems, cloud platform systems, network management systems, storage management systems, database management systems, device management systems, and application operation and maintenance systems, etc.

[0055] Specifically, each request task has processing attributes set, including automatic processing and manual processing. For each request task, the executor processes the received request task in the following ways:

[0056] Determine the processing attribute of the request task. If the processing attribute is automatic, the request task will be processed automatically according to the preset processing rules, and the processing status of the request task will be changed to "processing". When automatic processing is completed, the processing status of the request task will be changed to "completed". If the processing attribute is manual, the request task will be sent to the system of the corresponding handler so that the handler can manually process the request task, and the processing status of the request task will be updated according to the handler's modification operation on the task status in the system.

[0057] Here, for automatically processed request tasks, the decomposed request tasks can be sent to various domain systems for automatic execution. For manually processed request tasks, personnel need to log into the Ant system to handle them.

[0058] Understandably, the Ant system sets up a corresponding processing flow for each service request, and each processing flow corresponds to multiple request tasks. Each request task corresponds to multiple steps, and each step can be set to be executed automatically or manually (among which, synchronous execution, asynchronous execution, and silent execution are all types of automatic steps).

[0059] Once a request is approved, tasks in the request processing flow can be automated using scripts. If all tasks are automated, the process can complete the request without the intervention of maintenance personnel. Upon completion, SPlus notifies the applicant for verification. In a fully automated process without waiting for a change window, requests can be processed in seconds. The function parameters in the script are the data generated from the form filled out by the applicant after SPlus form configuration. The script can process the applicant's parameters, and the specific parameters of the script can be viewed after generating the specific task.

[0060] For manually processed requests, operations personnel handle the requests from a task-oriented perspective. They only need to log in to Ant to process the task and complete the corresponding content; they don't need to worry about compliance documents or the overall Ant process. The Ant system handles the interaction with request forms and change orders, and manages the overall workflow. Operations personnel don't need to log into multiple platforms to process request content while simultaneously processing request forms / change orders. They can click on the process flow of a task to view its execution status. Different task statuses have different processing methods: "Pending Claim" tasks require the implementer to accept the order, which then enters the "Pending Plan" status, or it can be reassigned to other members of the same team; after entering the "Pending Plan" status, a change order needs to be created, and after the change order is approved, it enters the "Pending Implementation" status. Once in the "Pending Implementation" status, automatically processed request tasks (set in the template whether the task is automatic or manual) will run directly, and the Ant backend handles the logic for the change order status change. Manually processed request tasks can be executed by clicking the "Process" button step by step; once all steps are completed, the task is finished. The first step begins with the Ant system synchronizing and updating the change order. The last step completes this process, ending with the Ant system synchronizing and updating the change order. Maintenance personnel no longer need to process change orders in other systems.

[0061] S105. Obtain the processing status of each request task sent by the executor. When the processing status of all request tasks is "completed", confirm that the service request work order corresponding to the target service request has been completed and notify the applicant to verify.

[0062] Once the task is completed, the Ant system will check if there are any unfinished request tasks in the process. If all request tasks are completed, the entire process will be automatically set to complete, and SPlus will be notified synchronously that the process corresponding to the request has been implemented. SPlus will then notify the applicant for verification.

[0063] The SPlus+Ant platform provided in this application embodiment can offer different form content for different scenarios. The values ​​for each form field can be obtained from static data, CMDB, and domain-specific data, greatly improving the flexibility of the forms. When a user submits a request, the form is validated, providing comprehensive and effective request data to operations and maintenance personnel, reducing offline communication costs, and improving the quality and efficiency of IT service delivery.

[0064] Fine-grained field management provides the foundation for automated request processing. Requests that can be processed automatically can be orchestrated on the Ant platform (during which production safety standards can be integrated, and processes that do not conform to these standards can be adjusted). Once a user submits a request, it can be processed automatically without requiring manual intervention from operations personnel on the corresponding operations platform. After the automated task completes, the request status is automatically processed, eliminating the need for manual handling of the request by operations personnel.

[0065] In one embodiment of this application, the form editing interface includes a form editing area, a control display area, and an attribute editing area. The control display area includes multiple functional control items. The attribute editing area is used to edit form attributes or control attributes. The form editing area is used to display the configured form. The corresponding service request editing interface is configured for each service request in the following way:

[0066] In response to the selection of a new form control in the form creation interface, the form editing interface is displayed. In response to dragging a functional control item in the control display area, the corresponding control configuration box is displayed in the form editing area; in response to selection of a control configuration box, edit, copy, and delete buttons are displayed within the control configuration box. In response to selection of an edit icon control displayed in the control configuration box, the control property editing interface is displayed in the property editing area to obtain the editing information for that functional control, thereby generating a service request option edit box corresponding to a request content; multiple different service request option edit boxes form a form corresponding to a service request, which is then displayed in the service request editing interface.

[0067] This also provides a form management interface for configuring the corresponding form for each service request, as well as a form editing interface where you can configure which service request option edit boxes are included in each form, along with control and form properties. Control properties are used to configure data source and population settings, as well as dynamic data population settings, such as data source type (dynamic or static), interface type (domain or internal), and request address.

[0068] The functional controls here are categorized into three main types: basic controls, advanced controls, and custom controls. Basic controls include single-line text, multi-line text, time pickers, counters, checkbox groups, dropdown menus, switches, passwords, and query inputs. Advanced controls include subforms, upload functions, cascading selectors, and form components. Custom controls include IP components, DNS request information, and expedited components.

[0069] In one embodiment of this application, the approval chain consists of multiple approvers with different permission levels arranged in ascending order of permission level, and the approval result of the service request work order corresponding to the target service request is obtained through the following method:

[0070] The service request ticket corresponding to the target service request is forwarded to the first approver in the approval chain. If the first approver approves the service request ticket, it is forwarded to the next approver. If the first approver disapproves the service request ticket, the approval result for the service request ticket corresponding to the target service request is determined to be disapproved. If all approvers approve the service request ticket, the approval result for the service request ticket corresponding to the target service request is determined to be approved.

[0071] Understandably, requests require approval, and the approvers are configured by the SPlus administrator. You can choose to set up an approval chain in SPlus, or the domain system can set up different approval chains based on the content filled in by the user.

[0072] Specifically, the approval chain can be configured as follows:

[0073] Based on the scope of permissions required for the target service's office needs, determine the corresponding multiple permission levels.

[0074] For each permission level, at least one approver is selected from all approvers at that permission level to approve the service request work order corresponding to the target service request.

[0075] Configure the approval chain in the SPlus system. You can choose an approval chain template or customize the approval chain for the current service item. Some services require determining the approval chain based on the information provided by the applicant. For example, "Operating room access control and user permission application" requires different approval chains depending on the environment and channel selected by the user. The higher the permission requested, the more people are involved in the approval chain.

[0076] The approval chain types here include internal and external approvals. Each approval chain can be a default template, such as the applicant's direct supervisor - group manager - department head format. Each approval chain has multiple approval nodes arranged sequentially, and each approval node can be assigned multiple approvers.

[0077] In one embodiment of this application, an interactive flow for a service request is provided. The applicant fills in the request content on the SPlus platform. Upon submission, the SPlus platform verifies the request content against the domain system for correctness. After successful verification and approval, the platform calls the Ant system for processing. For automated tasks, the Ant system calls the relevant domain systems for automatic implementation. For manual tasks, the implementer processes the task in the Ant system. After all Ant processes corresponding to the request have been completed, the SPlus system notifies the applicant to verify the request. The interactive flow diagram is as follows: Figure 4 As shown. The applicant here can be an employee with IT office needs, and the executor can be an executor or an execution system, such as a domain system or operations and maintenance personnel.

[0078] The interaction process includes:

[0079] 1) The applicant submits the application through the SPlus platform. Some fields on the form submission page need to be obtained by SPlus calling the interfaces of domain systems (such as IT systems, bastion host management systems, cloud platform systems, network management systems, storage management systems, database management systems, device management systems, application operation and maintenance systems, etc.).

[0080] 2) After the applicant fills in the request content, SPlus will call the domain system's verification interface to verify whether the request content filled in the application is correct (for example, "Apply to activate production VPN" will verify whether the applicant has registered a VPN and whether it is within the production VPN whitelist).

[0081] 3) Once SPlus verification is successful, proceed to the approval node. After approval, the Ant platform will be invoked to create the process.

[0082] 4) Ant creates a process based on the pre-arranged process template, and the process generates tasks;

[0083] 5) Automatic tasks on Ant will directly execute the script, and the script will call the domain system to perform specific tasks; manual tasks require the implementer to mark the task as completed after manual completion.

[0084] 6) After all tasks in the process are completed, Ant notifies SPlus that the request has been completed, and SPlus notifies the applicant to verify whether the request content has been successfully implemented.

[0085] This addresses the issue that existing ITSM platforms cannot provide personalized and automated business scenarios.

[0086] Based on the same inventive concept, this application also provides a service request processing device corresponding to the service request processing method. Since the principle of the device in this application for solving the problem is similar to the service request processing method described above in this application, the implementation of the device can refer to the implementation of the method, and the repeated parts will not be described again.

[0087] Please see Figure 5 , Figure 5 This is a schematic diagram of the structure of a service request processing apparatus provided in an embodiment of this application. Figure 5 As shown, the service request processing device 500 includes:

[0088] The response module 510 is used to respond to the applicant's selection of the target service request item in the service menu interface according to the IT office needs, and to display the service request editing interface corresponding to the target service request. The service menu interface displays multiple service request items corresponding to multiple service requests, and the service request editing interface displays multiple service request option editing boxes to obtain multiple request contents of the service request edited by the applicant.

[0089] Create module 520, which is used to create a service request work order corresponding to the target service request based on the obtained multiple request contents;

[0090] The judgment module 530 is used to determine whether the service request work order corresponding to the target service request meets the execution conditions.

[0091] The decomposition module 540 is used to decompose the service request work order corresponding to the target service request into multiple request tasks based on the processing flow corresponding to the target service request when the service request work order corresponding to the target service request meets the execution conditions, and send each request task to the corresponding executor for processing.

[0092] The receiving module 550 is used to obtain the processing status of each request task sent by the executor. When the processing status of all request tasks is completed, it confirms that the service request work order corresponding to the target service request has been completed and notifies the applicant to verify.

[0093] In a preferred embodiment, the form editing interface includes a form editing area, a control display area, and an attribute editing area. The control display area includes multiple functional control items. The attribute editing area is used to edit form attributes or control attributes. The form editing area is used to display the configured form. The response module 510 is also used to configure a corresponding service request editing interface for each service request in the following ways: responding to the selection operation of the new form control in the form creation interface, displaying the form editing interface; responding to the drag operation of the functional control item in the control display area, displaying the corresponding control configuration box in the form editing area; responding to the selection operation of the control configuration box, displaying an edit button, a copy button, and a delete button in the control configuration box; responding to the selection operation of the edit icon control displayed in the control configuration box, displaying the control attribute editing interface in the attribute editing area, obtaining the editing information for the functional control, and generating a service request option editing box corresponding to a request content; multiple different service request option editing boxes form a form corresponding to a service request, which is displayed in the service request editing interface.

[0094] In a preferred embodiment, the determination module 530 determines whether the service request work order corresponding to the target service request meets the execution conditions by: obtaining the verification result of the service request work order corresponding to the target service request from the executor; if the verification result of the service request work order corresponding to the target service request is passed, then submitting the service request work order corresponding to the target service request to the approval process to obtain the approval result of the service request work order corresponding to the target service request; if the approval result of the service request work order corresponding to the target service request is passed, then determining that the service request work order corresponding to the target service request meets the execution conditions.

[0095] In a preferred embodiment, the request task includes at least multiple service request items. The judgment module 530 obtains the verification result of the service request work order corresponding to the target service request from the executor in the following ways: for each request task, the request task is sent to the corresponding executor for verification; the executor verifies whether each service request item of the request task is within the production management scope according to the verification logic corresponding to the task type of the request task; and verifies whether each service request item of the request task is within the request execution scope according to the verification logic corresponding to the task type of the request task; if all service request items of each request task are within the production management scope and also within the request execution scope, then the verification result of the service request work order corresponding to the target service request is determined to be passed.

[0096] In a preferred embodiment, the approval chain consists of multiple approvers with different permission levels arranged in ascending order of permission. The judgment module 530 obtains the approval result of the service request work order corresponding to the target service request in the following manner: forwarding the service request work order corresponding to the target service request to the first approver in the approval chain; if the first approver approves the service request work order, then forwarding the service request work order to the next approver; if the first approver disapproves the service request work order, then determining that the approval result of the request task service request work order corresponding to the target service request is disapproved; if all approvers approve the service request work order, then determining that the approval result of the request task service request work order corresponding to the target service request is approved.

[0097] In a preferred embodiment, a configuration module (not shown in the figure) is further included, which is used to configure the approval chain in the following manner: determine multiple corresponding permission levels according to the permission scope required by the office needs of the target service request; for each permission level, determine at least one approver from all approvers of that permission level to approve the service request work order corresponding to the target service request.

[0098] In a preferred embodiment, each request task is configured with processing attributes, including automatic processing and manual processing. For each request task, an execution module (not shown in the figure) is also included to process the received request task in the following ways: determining the processing attribute of the request task; if the processing attribute of the request task is automatic processing, then automatically processing the request task according to preset processing rules and changing the processing status of the request task to "processing"; when automatic processing is completed, then changing the processing status of the request task to "completed"; if the processing attribute of the request task is manual processing, then sending the request task to the system of the corresponding handler so that the handler can manually process the request task, and updating the processing status of the request task according to the handler's modification operation of the task status in the system.

[0099] Please see Figure 6 , Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 6 As shown, the electronic device 600 includes a processor 610, a memory 620, and a bus 630.

[0100] The memory 620 stores machine-readable instructions executable by the processor 610. When the electronic device 600 is running, the processor 610 and the memory 620 communicate via the bus 630. When the machine-readable instructions are executed by the processor 610, they can perform the operations described above. Figure 1The steps of the service request processing method in the method embodiment shown are described in detail in the method embodiment, and will not be repeated here.

[0101] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, can perform the above-described actions. Figure 1 The steps of the service request processing method in the method embodiment shown are described in detail in the method embodiment, and will not be repeated here.

[0102] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0103] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Additionally, the shown or discussed mutual couplings, direct couplings, or communication connections may be through some communication interfaces; indirect couplings or communication connections between devices or units may be electrical, mechanical, or other forms.

[0104] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0105] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0106] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a processor-executable, non-volatile, computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0107] Finally, it should be noted that the above-described embodiments are merely specific implementations of this application, used to illustrate the technical solutions of this application, and not to limit them. The scope of protection of this application is not limited thereto. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features, within the scope of the technology disclosed in this application. Such modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be covered within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for processing service requests, characterized in that, The method includes: In response to the applicant's selection of the target service request item in the service menu interface based on IT office needs, a service request editing interface corresponding to the target service request is displayed. The service menu interface displays multiple service request items corresponding to multiple service requests, and the service request editing interface displays multiple service request option editing boxes to obtain multiple request contents of the service request edited by the applicant. Based on the obtained multiple request contents, create a service request ticket corresponding to the target service request; Determine whether the service request work order corresponding to the target service request meets the execution conditions; When the service request work order corresponding to the target service request meets the execution conditions, the service request work order corresponding to the target service request is decomposed into multiple request tasks based on the processing flow corresponding to the target service request, and each request task is sent to the corresponding executor for processing. Obtain the processing status of each request task sent by the executor. When the processing status of all request tasks is "completed", confirm that the service request work order corresponding to the target service request has been completed and notify the applicant to verify. The following methods are used to determine whether the service request work order corresponding to the target service request meets the execution conditions: Obtain the verification result of the service request work order corresponding to the target service request from the executor. For each request task, send the request task to the corresponding executor for verification. Obtain the verification logic corresponding to the task type of the request task from the executor to verify whether each service request item of the request task is within the production management scope, and to verify whether each service request item of the request task is within the request execution scope. If all service request items of each request task are within the production management scope and also within the request execution scope, then the verification result of the service request work order corresponding to the target service request is determined to be passed. If the verification result of the service request work order corresponding to the target service request is passed, the service request work order corresponding to the target service request will be submitted to the approval process to obtain the approval result of the service request work order corresponding to the target service request. If the approval result of the service request work order corresponding to the target service request is passed, then the service request work order corresponding to the target service request is determined to meet the execution conditions.

2. The method according to claim 1, characterized in that, The form editing interface includes a form editing area, a control display area, and an attribute editing area. The control display area includes multiple functional control items. The attribute editing area is used to edit form attributes or control attributes. The form editing area is used to display the configured form. A corresponding service request editing interface can be configured for each service request in the following ways: In response to a selection operation of the new form control in the form creation interface, the form editing interface is displayed; In response to a drag operation on a functional control item in the control display area, the corresponding control configuration box is displayed in the form editing area; In response to a selection operation on the control configuration box, an edit button, a copy button, and a delete button are displayed in the control configuration box; In response to the selection operation of the edit icon control displayed in the control configuration box, the control attribute editing interface is displayed in the attribute editing area to obtain the editing information for the function control, so as to generate a service request option editing box corresponding to a request content; Multiple different service request option edit boxes form a form corresponding to a service request, which is displayed in the service request editing interface.

3. The method according to claim 1, characterized in that, The approval chain consists of multiple approvers with different permission levels, arranged from lowest to highest permission level. The approval result of the service request ticket corresponding to the target service request is obtained through the following methods: Forward the service request work order corresponding to the target service request to the first approver in the approval chain; If the first approver approves the service request ticket, the service request ticket will be forwarded to the next approver. If the first approver fails to approve the service request ticket, the approval result of the request task service request ticket corresponding to the target service request is determined to be unsuccessful. If all approvers approve the service request ticket, then the approval result of the service request ticket corresponding to the target service request is indeed approved.

4. The method according to claim 3, characterized in that, Configure the approval chain as follows: Based on the scope of permissions required for the office needs of the target service request, determine the corresponding multiple permission levels; For each permission level, at least one approver is selected from all approvers at that permission level to approve the service request work order corresponding to the target service request.

5. The method according to claim 1, characterized in that, Each request task has processing attributes set, including automatic processing and manual processing. For each request task, the executor processes the received request task in the following ways: Determine the processing attributes of the request task; If the processing attribute of the request task is automatic, the request task will be automatically processed according to the preset processing rules, and the processing status of the request task will be changed to processing. When the automatic processing is completed, the processing status of the request task will be changed to completed. If the processing attribute of the request task is manual, the request task will be sent to the system of the corresponding handler so that the handler can manually process the request task, and the processing status of the request task will be updated according to the handler's modification operation on the task status of the request task in the system.

6. A service request processing apparatus, characterized in that, A method for processing a service request according to any one of claims 1-5, the apparatus comprising: The response module is used to respond to the applicant's selection of the target service request item in the service menu interface according to the IT office needs, and to display the service request editing interface corresponding to the target service request. The service menu interface displays multiple service request items corresponding to multiple service requests, and the service request editing interface displays multiple service request option editing boxes to obtain multiple request contents of the service request edited by the applicant. The creation module is used to create a service request ticket corresponding to the target service request based on the multiple request contents obtained; The judgment module is used to determine whether the service request work order corresponding to the target service request meets the execution conditions. The decomposition module is used to decompose the service request work order corresponding to the target service request into multiple request tasks based on the processing flow corresponding to the target service request when the execution conditions are met, and send each request task to the corresponding executor for processing. The receiving module is used to obtain the processing status of each request task sent by the executor. When the processing status of all request tasks is completed, it confirms that the service request work order corresponding to the target service request has been completed and notifies the applicant to verify it.

7. An electronic device, characterized in that, include: The device includes a processor, a memory, and a bus. The memory stores machine-readable instructions executable by the processor. When the electronic device is running, the processor communicates with the memory via the bus, and the processor executes the machine-readable instructions to perform the steps of the service request processing method as described in any one of claims 1 to 5.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, performs the steps of the service request processing method as described in any one of claims 1 to 5.

Images