Error handling during service bootstrapping

Abstract

Techniques and systems are described herein for monitoring guided engagement sessions and storing guided information associated with completion of tasks of the monitored guided engagement sessions. Using the guided information, errors common to at least some of the tasks from the guided engagement sessions can be determined, and solutions can be identified so that solutions can be recommended in response to runtime errors in the current guided session.

Description

[0001] This application is a divisional application of a Chinese patent application filed on November 21, 2016, with application number 201680071011.6 and invention name “Error Handling During Service Bootstrap”. Background Art

[0002] Recently, more and more organizations are switching from using their own computing infrastructure to using a network computing infrastructure operated and managed by a service provider (e.g., a third-party service provider). For example, a company typically uses an agent (e.g., an information technology (IT) administrator) to set up and manage the company's own on-premises server that hosts an email service or other services provided to the company's employees. However, recently, it may be more cost-effective to have a service provider use a network computing infrastructure hosting service.

[0003] Bootstrapping refers to the process and / or mechanisms of helping a customer organization (e.g., which may also be referred to as a customer or tenant) establish a service on a network computing infrastructure operated and managed by a service provider. In many cases, establishing a service on a network computing infrastructure includes moving at least a portion of the service from the customer organization's own computing infrastructure to the network computing infrastructure. The goal of bootstrapping is to effectively and efficiently configure the service on the network computing infrastructure so that the customer organization fully participates and various devices within the customer organization are able to interact with the service after the service is bootstrapped (e.g., an employee device can access an email mailbox hosted by a cloud server instead of or as a replacement for an on-premises server).

[0004] Bootstrapping typically requires a large number of tasks that must be performed, for example, by an agent of the customer organization (e.g., an IT administrator). For example, at the beginning of the bootstrapping process, the customer organization is often provided with a long and exhaustive list of different tasks (e.g., more than two hundred tasks), each of which may not even be necessary and / or relevant to bootstrapping a particular service to the network computing infrastructure according to the customer organization's expectations. The list of different tasks is typically pre-ordered and is the same for all customer organizations, regardless of the size of the customer organization or the customer's expectations related to bootstrapping the service.

[0005] As a result, many client organizations experience difficulty navigating through the onboarding process in order to not only identify the related tasks to be completed, but also determine the best and efficient order for completing the related tasks. Instead, the list of different tasks that is typically provided to the client organization at the beginning of the onboarding process provides limited or no guidance, and the order in which the tasks are to be completed is not effectively updated during the onboarding process. This results in the client disengaging from the onboarding process. Summary of the invention

[0006] Described herein are techniques and systems for guiding at least a portion of a service from a computing infrastructure managed by a customer to a network computing infrastructure. As part of the guidance, a database storing guidance information is accessed and a set of tasks is identified. A state diagram is generated based on the guidance information, wherein the state diagram models the dependencies between the individual tasks in the set of tasks. In some cases, the state diagram may include a finite state machine configured to detect a current state and a state transition trigger to move to a next state (e.g., a next best state). The techniques and systems are configured to calculate a task execution path within the state diagram, the task execution path being associated with the highest probability of success for moving a customer organization from a current environment associated with a computing infrastructure managed by the customer to a target environment associated with a network computing infrastructure. The task execution path can be used to identify and provide a subset of tasks implemented by a customer organization. In various examples, the task execution path can be recalculated based on customer feedback (e.g., indicating an attempt to implement a separate task, but the completion of the separate task was unsuccessful). In various examples, the task execution path can be recalculated based on the determination that a separate task was not completed within the expected amount of time to complete the separate task.

[0007] In addition, the techniques and systems described herein monitor guided engagement sessions and store guided information associated with task completion of the monitored guided engagement sessions. Using the guided information, errors common to at least some of the tasks from the guided engagement sessions can be determined, and solutions can be identified so that these solutions can be recommended in response to runtime errors in the current guided session.

[0008] This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] The detailed description is described with reference to the accompanying drawings. In the figures, the leftmost digit(s) of a reference number identifies the figure in which the reference number first appears. The same reference numbers in different figures indicate similar or identical items.

[0010] Figure 1 An example environment is shown in which a service provider and / or customer organization implements a directed engagement session to direct services to a network computing infrastructure.

[0011] Figure 2 is a schematic diagram illustrating components of an exemplary boot device that may be part of a service provider that assists in booting services to a network computing infrastructure.

[0012] Figure 3An example database is illustrated in which boot information collected from a plurality of monitored boot engagement sessions may be stored and accessed to facilitate bootstrapping of services to a network computing infrastructure.

[0013] Figure 4 A flow chart illustrating an example process for generating a state diagram that models dependencies between tasks in a set of tasks identified by a service provider for steering services for a customer organization.

[0014] Figure 5 A flow chart illustrating an example process of calculating task execution paths associated with the highest probability of success for directing a service to a network computing infrastructure and updating a deployment plan based on customer feedback.

[0015] Figure 6 An example graphical user interface is shown that a customer organization and / or a service provider may use to view a list of tasks to be completed and / or the status of individual tasks.

[0016] Figure 7 Illustrated is an example graphical user interface that individual users of a client organization and / or a service provider involved in a lead engagement session may use to provide feedback on individual tasks.

[0017] Figure 8 A flow chart illustrating an example process for recalculating a task execution path based on customer feedback indicating that an individual task has not been successfully completed.

[0018] Fig. 9 A flow chart of an example process for determining errors common to multiple guided engagement sessions and identifying solutions to the errors is shown.

[0019] Fig.10 A flow chart of an example process for providing a solution in response to determining an occurrence of a runtime error in a current guided engagement session is shown.

[0020] Fig.11 A flow chart illustrating an example process of calculating task execution paths associated with the highest probability of success for directing a service to a network computing infrastructure and updating a deployment plan based on automatic and continuous monitoring of the status of individual tasks.

[0021] Fig.12 A flow chart of an example process for automatically identifying and implementing a solution in response to determining an occurrence of a runtime error in a current guided engagement session is illustrated. DETAILED DESCRIPTION

[0022] The techniques and systems described herein provide assisted guidance for customer organizations by identifying guidance tasks that, when implemented, move customer organizations from a current environment using customer-controlled resources to a target environment using network resources. Guidance information collected from previous guidance processes can be used to identify guidance tasks and the order in which guidance tasks are executed. Therefore, the techniques and systems described herein are configured to monitor a large number of guidance processes and store guidance information related to the monitored guidance processes. Therefore, historical knowledge indicating which actions have successfully and / or unsuccessfully completed tasks can be used to improve future guidance processes and ensure that customers continue to participate in the guidance process. For example, the techniques and systems described herein can determine: individual tasks that customer organizations have difficulty completing, individual tasks that customer organizations have easily completed, individual tasks that cause delays and / or errors, solutions implemented to avoid delays and / or resolve errors, and the best execution order of various tasks to ensure that customers participate in the guidance process (e.g., reduce the possibility of disengagement), etc. In various implementations, the techniques and systems use historical knowledge to implement supervised learning and lead the autonomous guidance process based on the learning probability that the completion of the selected next task effectively moves the customer organization to full participation (e.g., a complete solution to the guidance process).

[0023] Therefore, the technology and system described herein can provide a guidance method that is customized for a single client organization and provides guidance assistance that effectively and efficiently guides the client organization to the target environment from the current environment according to the expectations of the client organization. For example, the execution order of the task to be completed can be dynamically updated (for example, can be changed) based on the determined state transition and / or error state. For this reason, these technologies and systems generate a state diagram (for example, a finite state machine) based on the guidance information, wherein the state diagram includes a nonlinear model, and the nonlinear model provides various paths that can be followed to move the client organization from the current environment to the target environment (for example, the execution order of the node that the path includes the individual node in the state diagram represents the task). The state diagram includes the task execution path associated with the highest success probability for guiding the service to the network computing infrastructure. Therefore, the state diagram is used to continuously update the order of implementing the task by a specific client organization in the entire guidance process. That is to say, the technology and system described herein can recalculate the task execution path associated with the highest success probability in the state diagram based on whether the task is successfully completed.

[0024] In at least one example, the order in which tasks are to be performed by a particular client organization is based on client feedback explicitly provided by the particular client organization, the client feedback indicating whether the current task has been successfully completed. In at least one alternative example, the order in which the particular client organization is to perform tasks is based on automatic and continuous monitoring of the status of individual tasks (e.g., performed by a service provider). For example, a current task attempted to be completed by a particular client organization may be associated with an error state determined based on explicit client feedback or automatic / detected feedback. The error state may be used to change the order in which a set of tasks are to be performed. Thus, it may be determined that the client organization is having difficulty completing a particular task, or that the client organization has failed to complete a particular task.

[0025] Thus, in contrast to conventional approaches that provide a long list of pre-ordered tasks at the beginning of the boot process and provide little or no assistance to the client organization thereafter, the techniques and systems described herein are configured to use boot information to identify and / or recommend tasks throughout the boot process. This increases the likelihood that the client organization remains engaged until the boot process is complete (e.g., the client organization is able to use services hosted by the network computing infrastructure).

[0026] Figure 1 An example environment 100 is shown in which a service provider 102 bootstraps a service 106 for a client organization 104. As described above, bootstrapping refers to the process and / or mechanism that enables the client organization 104 to establish the service 106 on a network computing infrastructure 108 operated and managed by the service provider 102. In many cases, establishing the service 106 on the network computing infrastructure 108 includes moving at least a portion of the service 106 from a customer-managed computing infrastructure 110 to the network computing infrastructure 108. The customer-managed computing infrastructure 110 includes customer-controlled resources 112 (e.g., processing resources, storage resources, security resources, network resources, etc.). For example, the customer-controlled resources 112 may include an on-premises server or other device that hosts an email service for the client organization 104 (e.g., where the on-premises server is located in a physical structure where the company operates). In an alternative example, at least some of the customer-controlled resources 112 may also include resources that are not on-premises, but rather are externally deployed, but still under the control and management of the client organization 104.

[0027] The network computing infrastructure 108 includes network resources 114. For example, the network resources 114 may include servers or other devices including data centers, server farms, or other cloud configuration resources. In various implementations, the network resources 114 are scaled resources so that they can be shared across multiple different customer organizations (e.g., including the customer organization 104). In various cases, the customer organizations may pay a fee (e.g., a monthly or annual subscription fee) to contract with the service provider 102 to host at least a portion of the service 106 via the network resources 114.

[0028] Establishing at least a portion of the service 106 on the network computing infrastructure 108 may be implemented within the guided engagement session 116. As described above, in many cases, the goal of the guided engagement session 116 is to effectively and efficiently move at least a portion of the service 106 from the customer-managed computing infrastructure 110 to the network computing infrastructure 108 so that the customer organization 104 can fully participate in the service 106 on the network computing infrastructure 108.

[0029] As part of the guided engagement session 116, the service provider 102 generates a set of tasks 118 that assist in establishing the service 106 on the network computing infrastructure 108. In some examples, establishing the service 106 on the network computing infrastructure 108 includes moving at least a portion of the service 106 from a current environment 120 that uses customer-controlled resources 112 to a target environment 122 that uses, at least in part, network resources 114. In various implementations, the customer organization 104 (e.g., a representative or agent, such as an IT administrator contracted or employed by the customer organization 104) is responsible for completing the tasks or at least a portion of the tasks. In various implementations, the service provider 102 (e.g., an on-call engineer (OCE) contracted or employed by the service provider 102) is responsible for completing the tasks or at least a portion of the tasks. In various implementations, the customer organization 104 and the service provider 102 work together to complete the tasks (e.g., share responsibility).

[0030] The current environment 120 represents how the service 106 is currently set up and configured using the customer-controlled resources 112. For example, the current environment 120 may define the characteristics of the service (e.g., a number of organizational users of the service, identities of organizational users, number of devices used by organizational users of the customer organization 104, storage capacity of individual mailboxes, etc.), capabilities of the service (e.g., enabling mobile access to email mailboxes), and / or functionality enabled for the service (e.g., enabling security features, user preferences and / or privileges, etc.). Thus, the current environment 120 may represent the hardware and / or software configuration of the service 106 on the customer-managed computing infrastructure 110.

[0031] The service provider 102 is configured to determine a target environment 122 such that the network resources 114 of the network computing infrastructure 108 can be used to similarly target the features, capabilities, and / or functions of the services in the current environment 120. The target environment 122 can be determined based on input provided by the client organization 104, wherein the input defines the expectations of the client organization 104. For example, the input and expectations can include operational requirements, instructions for enabling or disabling specific features, a timeline for moving services (e.g., bootstrap 10% of employee mailboxes during the first month, bootstrap 20% of employee mailboxes during the second month, bootstrap 30% of employee mailboxes during the third month, etc.), etc. Thus, depending on the expectations of the client organization 104 and the number and difficulty of the associated bootstrap tasks 118 to be completed, the bootstrap engagement session 116 can take hours, days, weeks, months, or even years to complete.

[0032] In various examples, services 106 may include an email service (e.g., an email exchange service), a document sharing service, a document storage service, a video conferencing service, a social networking service (e.g., for an enterprise), etc. In some cases, services 106 may include a combination of multiple services among email services, document sharing services, document storage services, video conferencing services, social networking services, etc. Thus, by directing engagement session 116, at least a portion of services 106 is configured and arranged for client devices 124 associated with client organization 104 (hereinafter referred to as client devices 124).

[0033] Client device 124 may be any device including, but not limited to, a personal computer device, a laptop computer device, a desktop computer device, a portable digital assistant (PDA) device, a mobile phone device, a smartphone device, a tablet device, an electronic book (eBook) reader device, a set-top box device, a game console device, a smart television device, a wearable device (e.g., a smart watch, electronic "smart" glasses, a fitness tracker, etc.), or any other electronic device. In some examples, client device 124 may be a server or other network accessible device that is part of a client-managed computing infrastructure 110.

[0034] In one example, guidance is implemented to implement a "hybrid" service that uses both the customer-managed computing infrastructure 110 and the network computing infrastructure 108 (e.g., an email hybrid service in which individual users have mailboxes stored on-premises and linked mailboxes stored in the cloud). This enables the customer organization 104 to extend the experience and management control it has over the existing customer-managed computing infrastructure 110 (e.g., the on-premises infrastructure) to the network computing infrastructure 110. An exemplary task 118 to be implemented to implement the email hybrid service may be to add acceptable domains to the customer-managed computing infrastructure 110 to allow mail flow. Another example task 118 to be implemented to implement the email hybrid service may be to update an Active Directory object in the customer-managed computing infrastructure 110 so that it contains hybrid deployment configuration parameters that can be used to configure on-premises mailbox settings and linked network mailbox settings (e.g., secure mail routing between on-premises mailboxes and linked network mailboxes, mail routing with a shared domain namespace, a unified global address list (GAL) shared between on-premises mailboxes and linked network mailboxes, calendar sharing between on-premises mailboxes and linked network mailboxes, etc.).

[0035] Conducting the participation session 116 may be implemented over a network 126. In addition, the client organization 104 and / or the client device 124 are configured to use the service 106 (e.g., access an email mailbox, share documents in a collaborative environment, participate in a video conference, etc.) via the network 126. To this end, the network 126 may include a wide area network (WAN), a local area network (LAN), a personal area network (PAN), a data center-specific network (e.g., an intranet, a storage area network (SAN)), etc. The network may also include various devices (e.g., Figure 1 The servers and / or storage devices shown in the figure) are connected to switches of routers and / or other devices that can act as bridges between data networks. Communications between devices can utilize any type of communication protocol known in the art for sending and receiving information and / or messages, such as Transmission Control Protocol / Internet Protocol (TCP / IP) and / or User Datagram Protocol (UDP).

[0036] As described above, a state diagram (e.g., a finite state machine) generated based on previously collected bootstrap information can be used to identify tasks 118. As part of a deployment plan, service provider 102 can provide or recommend tasks 118 to client organization 104. Thus, a state diagram can be used to update the order in which tasks 118 are to be performed throughout the bootstrap engagement session 116. As an example, a domain verification task can be a precursor to a task that provides an organization identifier (ORGID) that an employee can use to connect a mobile device (e.g., client device 124) to a bootstrap service (e.g., service 106).

[0037] In various implementations, the guidance information used to generate the state map can be specific to a particular segment of a customer organization, where the different segments can be based on different sizes of customer organizations (e.g., number of users, number of devices, etc.). For example, efficient and effective guidance assistance provided to a small business with only three employees may be different than efficient and effective guidance assistance provided to a large enterprise with hundreds or thousands of employees and its own information technology (IT) department.

[0038] Figure 2 is a schematic diagram illustrating components of an example boot device 200 , which may be part of a service provider 102 that boots a service 106 to a network computing infrastructure 108 .

[0039] The boot device 200 may include one or more processors 202 and a memory 204 and a network interface 206 so that the boot device 200 can communicate with the customer organization 104 (e.g., the customer device 124). The processor 202 may be a single processing unit or multiple units, each of which may include multiple different processing units. The processor 202 may include a microprocessor, a microcomputer, a microcontroller, a digital signal processor, a central processing unit (CPU), a graphics processing unit (GPU), etc. Alternatively or additionally, some or all of the techniques described herein may be performed at least in part by one or more hardware logic components. For example, but not limited to, exemplary types of hardware logic components that may be used include field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application specific standard products (ASSPs), state machines, complex programmable logic devices (CPLDs), other logic circuits, systems on chip (SoCs), and / or any other device that performs operations based on instructions. Among other capabilities, the processor 202 may be configured to obtain and execute computer-readable instructions stored in the memory 204.

[0040] The memory 204 may include one or a combination of computer readable media. As used herein, "computer readable media" includes computer storage media and communication media.

[0041] Computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Computer storage media include, but are not limited to, phase change memory (PCM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable ROM (EEPROM), flash memory or other memory technology, compact disk ROM (CD-ROM), digital versatile disk (DVD) or other optical storage devices, magnetic cassettes, magnetic tapes, magnetic disk storage or other magnetic disk storage devices, or any other medium that can be used to store information for access by a computing device.

[0042] In contrast, communication media includes computer readable instructions, data structures, program modules or other data in a modulated data signal (eg, carrier wave). As defined herein, computer storage media does not include communication media.

[0043] The memory 204 may also include an operating system that is configured to manage hardware and services within and coupled to the boot device 200 to facilitate other components and other devices. As an example, the memory 204 may include an observation module 208, a customer interaction module 210, a deployment plan module 212, an error module 214, and a solution module 216, each of which is further described herein. For ease of discussion, the deployment plan module 212 may further include a task identification module 218 and a task state module 220, each of which may be configured to perform functions using a state diagram 222. As used herein, the term "module" is intended to represent an example division of executable instructions for discussion purposes, and is not intended to represent any type of demand or required method, manner, or organization. Therefore, although various "modules" are described, their functions and / or similar functions may be arranged differently (e.g., combined into a smaller number of modules, divided into a larger number of modules, etc.). In addition, although certain functions and modules are described herein as being implemented by software and / or firmware that can be executed on a processor, in other embodiments, any or all modules may be implemented in whole or in part by hardware (e.g., a dedicated processing unit, etc.) to perform the described functions. In various implementations, the modules associated with the boot device 200 described herein may be executed on multiple devices.

[0044] In various implementations, the memory 204 may also include boot information 224 . Figure 3 An example database 300 is shown in which guidance information 224 collected from a plurality of monitored guidance engagement sessions may be stored.

[0045] In various examples, the observation module 208 is configured to observe and / or receive the current environment 120 of the customer-managed computing infrastructure 110 hosting the service 106 at the start of the guided engagement session 116. As described above, the current environment 120 represents how the service 106 is currently established and configured using the customer-controlled resources 112. For example, the current environment 120 may define the characteristics of the service 106 (e.g., the number of organizational users of the service, the identities of the organizational users, the number of devices used by users of the customer organization 104, the storage capacity of individual mailboxes, etc.), the capabilities of the service 106 (e.g., enabling mobile access to email mailboxes), and / or the functionality enabled for the service 106 (e.g., policies or user privileges associated with email mailboxes, implementation of security features, individual user service mailbox preferences, etc.). The current environment 120 may also define the type of hardware used to host the service 106 (e.g., security hardware, video conferencing equipment, etc.). The observation module 208 is also configured to monitor and / or receive information associated with completing tasks within the guided engagement session. In some cases, the monitored information associated with task completion may be stored as guidance information 224 so that it may be accessed and used in future guidance engagement sessions, as described herein with respect to Figure 3 For example, the stored guidance information 224 can be used to implement supervised learning and lead an autonomous guidance process (e.g., a complete solution to the guidance process) based on the learned probability that completion of the selected next task will effectively move the client organization to full engagement.

[0046] In various examples, the customer interaction module 210 is configured to receive customer input that defines expectations from which the target environment 122 of the service 106 may be determined. For example, the customer input may be received at the beginning of the guided engagement session 116 or during the guided engagement session 116, and may include operational requirements for the service 106, instructions for enabling or disabling specific features of the service 106, a timeline for moving the service 106 from the customer-managed computing infrastructure 110 to the network computing infrastructure 108, etc. The customer interaction module 210 may also receive customer input associated with a task completion status (e.g., completion time, indication of difficulty to complete, etc.).

[0047] In various examples, the deployment plan module 212 is configured to generate a deployment plan to bootstrap the service 106 to the network computing infrastructure 108. As described above, the deployment plan includes a set of tasks 118, and the deployment plan module 212 is configured to generate a state diagram 222 and then create the deployment plan using the state diagram 222. The deployment plan module 212 is also configured to continuously update the deployment plan throughout the bootstrap engagement session 116 (e.g., based on explicit customer feedback, based on automatic and continuous monitoring feedback, based on supervised learning, etc.).

[0048] The deployment plan module 212 generates the state diagram 222 using the boot information 224. The boot information 224 includes information monitored from a previous boot engagement session and / or information derived or calculated from a previous boot engagement session. For example, Figure 3 An example database 300 is shown storing boot information 224, where the boot information 224 can be organized according to the type of service 302 to be booted and / or a particular segment 304. The segment 304 is based on the size of the customer organization 104 (e.g., the number of users supported by the service to be booted, the number of devices supported by the service to be booted, etc.). There are many different ways to distinguish one segment from the next, but one example is to define the segments based on ranges (e.g., one to ten employees or devices comprises a first segment, eleven to fifty employees or devices comprises a second segment, fifty to five hundred employees or devices comprises a third segment, etc.). Thus, for each combination of service 302 and segment 304, the boot information 224 includes session identifiers (IDs) 306(1)...306(N) of previously monitored boot engagement sessions, and each session ID 306(1)...306(N) is associated with monitored session information 308(1)...308(N). In various examples, for each task completed in a monitored guided engagement session, the monitored session information 308(1)...308(N) includes an amount of time to complete the task and an indication related to difficulty of completion (e.g., such as a sentiment of "hard," "normal," or "easy"). For example, the monitored session information 308(1) may indicate that a task associated with a domain name system (DNS) update took three days to complete, and that completion of the DNS update was "hard," rather than "easy," for a particular client organization 104. Thus, the monitored session information 308(1)...308(N) may reveal tasks that resulted in extended delays within a guided engagement session and / or resulted in the client organization abandoning or disengaging from the guided engagement session.

[0049] Using the monitored session information 308(1)...308(N) collected across the plurality of session IDs 306(1)...306(N), the deployment planning module 212 can calculate or derive aggregate information 310 for a particular segment. For example, the aggregate information can include an expected amount of time to complete a task 312 (e.g., a calculated average time to complete the task based on the actual completion times monitored within each session ID 306(1)...306(N)) and an overall difficulty 314 to complete the task (e.g., a sentiment such as "easy," "medium," "hard," etc.). The overall difficulty 314 to complete the task can also be an average derived from the monitored session information 308(1)...308(N) stored for the individual session IDs 306(1)...306(N). Thus, in various examples, the client organization is able to provide input as to which tasks are difficult. Additionally, the service provider is also able to continually monitor the lead engagement sessions and determine which tasks are difficult (e.g., based on determining that the completion of the task takes longer than the expected amount of time to complete 312).

[0050] Thus, the guidance information 224 used by the deployment plan module 212 to generate the state diagram 222 can be specific to a particular segment of the client organization. To this end, the deployment plan module 212 can use the guidance information 224 to identify the entire set of tasks (e.g., tasks 118) that are relevant to the client organization and the client organization's expectations to be modeled by the state diagram 222. In other words, by using the guidance information 224, the deployment plan module 212 can reduce a typically long and exhaustive list of tasks (e.g., hundreds of tasks) and avoid including tasks that are not relevant to the particular segment.

[0051] Dependencies between tasks are defined within the state diagram 222 based on the guidance information 224, such that the state diagram 222 includes multiple paths that the guided engagement session 116 may follow (eg, the state diagram 222 is a non-linear graph). Return to Reference Figure 2 , the task identification module 218 is configured to identify a first subset of tasks to be completed within the guided engagement session 116 using the state diagram 222 .

[0052] In contrast to conventional bootstrapping methods that provide a long and exhaustive list of pre-ordered tasks, the identification of the first subset of tasks performed by the task identification module 218 does not include all of the tasks 118 required to bootstrap the service 106. Instead, the first subset of tasks includes an initial small set of tasks (e.g., one task, two tasks, three tasks, four tasks, five tasks, etc.) that are included along the task execution path in the state diagram 222 that provides the highest probability of success in moving the customer organization 104 from the current environment 120 to the target environment 122. Thus, for each node representing a task in the state diagram 222, the deployment plan module 212 performs statistical inference (e.g., using theories such as Bayes' theorem) on the bootstrapping information 224 to calculate the probability of successfully completing the task (e.g., an "event") based on conditions and / or dependencies (e.g., successful completion of other tasks or other "events"). The task identification module 218 then evaluates the various probabilities (e.g., individually and as a combination of probabilities built on top of each other) to determine the task execution path in the state diagram 222 that provides the highest probability of success. The task identification module 218 can then identify (e.g., select) a first subset of tasks (e.g., but not all tasks) along the calculated task execution path. The task identification module 212 ultimately provides the first ordered subset of tasks as part of the deployment plan to the customer organization 104. In various examples, the task execution path can include a partial Euler path.

[0053] After providing the first ordered subset of tasks, input associated with a completion status of the individual tasks is received. The input may indicate that the individual tasks have been successfully completed or unsuccessfully completed (e.g., the client organization 104 failed and was unable to complete the task, completion of the task was delayed due to difficulty, the task was not completed within an expected amount of time, etc.). In various examples, the input may be client-provided feedback that explicitly indicates the status, client-provided feedback received via the client interaction module 210. In alternative examples, the input may be implicit input based on automatic and continuous monitoring performed by the observation module 208. For example, the observation module 208 may receive information and determine that the client organization 104 did not successfully complete the task within the expected amount of time 312 to complete the task.

[0054] Based on the input, the task status module 220 can update the nodes in the state diagram 222 so that the task (e.g., the first subset of tasks attempted to be implemented) is marked as "successfully completed" or "unsuccessfully completed." The task identification module 218 then identifies (e.g., selects) a second subset of tasks along the task execution path after the first subset of tasks is completed or uncompleted. The task identification module 212 provides the second subset of tasks to the client organization as part of an updated deployment plan.

[0055] In various examples, if all tasks in the first subset of tasks have been successfully completed, the task execution path will not change. Accordingly, the second subset of tasks is selected from the same task execution path from which the first subset of tasks was selected. However, in an alternative example in which the task state module 220 updates the state diagram 222 to reflect that the tasks in the first subset of tasks have not been successfully completed, the deployment plan module 212 may recalculate the probabilities and task execution paths within the state diagram 222. Thus, the task execution paths recalculated based on the input may change (e.g., an initial path determined before selecting the first subset of tasks may be different from a subsequent path determined after the input indicates that the tasks in the first subset of tasks have not been successfully completed).

[0056] Thus, the deployment plan module 212 is configured to use stored onboarding information 224 from similarly located customer organizations to generate a state diagram 222 for the current onboarding engagement session 116. The deployment plan module 212 can continue to recommend a small number of tasks to be completed (e.g., one task, two tasks, three tasks, four tasks, five tasks, etc.) based on input indicating successful or unsuccessful completion of tasks and / or transitions between tasks. This more refined and sophisticated onboarding assistance based on continuous re-evaluation of the task execution paths with the highest likelihood of success can result in higher customer satisfaction associated with the onboarding process. In other words, the deployment plan module 212 uses previously learned historical knowledge for a particular segment to understand (i) where the customer organization 104 is within the onboarding engagement session 116 (e.g., which tasks have been successfully completed and which tasks were attempted but not successfully completed), and (ii) which next task is the best task that the customer organization 104 should attempt to implement in the onboarding engagement session to reduce the likelihood of customer disengagement. In various implementations, the deployment planning module 212 uses the saved guidance information 224 to perform supervised learning and lead the autonomous guidance process based on the learned probability that completion of the selected next task effectively moves the client organization to full engagement.

[0057] As described above, the observation module 208 is configured to monitor, receive and store information associated with the plurality of guided engagement sessions. In various examples, the error module 214 is configured to evaluate the stored information (e.g., the guided information 224) and determine errors common to tasks in at least some of the plurality of guided engagement sessions. Errors may prevent or delay completion of a task.

[0058] The solution module 216 can be configured to also evaluate the stored information and identify one or more solutions implemented to resolve the error (e.g., previous actions taken to resolve the error). In various examples, the errors and solutions can each be added to a supervised data set for incremental learning (e.g., machine learning). The error module 214 and the solution module 216 can store information associated with common errors and solutions to common errors in a database of the guide information 224 (e.g., according to a specific segment). Therefore, when a runtime error is detected in the current guide engagement session 116, the error module 214 can determine whether the runtime error is a common error and / or whether the solution module 216 can provide a solution to the runtime error to the client organization. As an example, the error module 214 can detect a runtime error in response to determining that the current task has not been successfully completed within the expected amount of time to complete the task.

[0059] In various examples, the solution module 216 can recommend one of multiple possible solutions. In addition, the solution module 216 can calculate and / or provide a confidence rating associated with the recommended solution. For example, the error module 214 can detect that the client organization encounters an error and cannot complete the DNS update task. Using the guidance information 224, the solution module 216 previously determined that there is an 85% chance that the error can be resolved by accessing a third-party domain name registrar and entering a password. Therefore, the solution module 216 can provide instructions to access a third-party domain name registrar and enter a password so that the DNS update task can be successfully completed as a recommended solution. Of course, other confidence ratings can be associated with alternative solutions (e.g., a 5% confidence rating for the second solution, a 3% confidence rating for the third solution, etc.). In some cases, when there is only one possible solution, the confidence may be 100% or close to 100%.

[0060] Figure 4 as well as Figure 5 and Figure 8-12 The example processes using the techniques described herein are shown separately. For ease of explanation, the example processes are described as Figure 1 The example process may be performed in the environment 100 of FIG. 200. In addition, the example process may be implemented by the boot device 200. However, the example process may also be performed in other environments and by other devices.

[0061] The example process is illustrated as a logical flow diagram, each operation of which represents a sequence of operations that can be implemented in hardware, software, or a combination thereof. In the context of software, an operation represents a computer-executable instruction stored on one or more computer-readable storage media that configures a device to perform the operation when executed by one or more processors. Typically, computer-executable instructions include routines, programs, objects, components, data structures, etc. that perform specific functions. The order in which the operations are described is not intended to be interpreted as a limitation, and any number of the described operations may be combined in any order and / or in parallel to implement the process. In addition, any individual operation may be omitted.

[0062] Figure 4 A flow chart is shown of an example process 400 for generating a state diagram that models dependencies between tasks in a set of tasks identified by a service provider for steering services for a customer organization.

[0063] At 402, a current environment 120 of a customer-managed computing infrastructure 110 is observed and / or information associated with the observation is received. As described above, the current environment 120 represents how the service 106 is currently established and configured using the customer-controlled resources 112. The current environment 120 may define characteristics of the service 106 (e.g., the number of organizational users of the service, the identities of the organizational users, the number of devices used by organizational users of the customer organization 104, the storage capacity of individual mailboxes, etc.), capabilities of the service 106 (e.g., enabling mobile access to email mailboxes), and / or functionality enabled for the service 106 (e.g., enabling security features, user preferences and / or privileges, etc.). The observation module 208 may observe and / or receive the current environment 120.

[0064] At 404, customer input is received (eg, from customer organization 104) that defines expectations for target environment 122. For example, customer input and expectations may include operational requirements, instructions to enable or disable specific functionality, timelines for mobile services, and so forth.

[0065] At 406, the bootstrap information 224 is accessed to identify a set of tasks 118 to be moved from the current environment 120 to the target environment 122. In various examples, the identified tasks 118 are selected from a large set of tasks based on their relevance to: (i) the type of service 106 being bootstrapped, and (ii) a particular segment associated with the customer organization 104 (e.g., the customer organization 104 may be a small company with five employees or a large company with five hundred employees). As illustrated in conjunction with operation 406, example tasks may include creating a user, verifying a domain, changing a domain name controller (DNC), connecting a customer device, migrating data, etc.

[0066] At 408, a state graph 222 (e.g., a finite state machine) is generated that models the dependencies between the individual tasks in the task set 118. The state graph 222 includes a non-linear model that provides various paths that can be followed to move the customer organization 104 from the current environment 120 to the target environment 122 (e.g., the paths include an execution order of nodes, where individual nodes of the state graph represent tasks).

[0067] Figure 5 A flow diagram of an example process 500 is shown that computes task execution paths associated with the highest probability of success for directing services to the network computing infrastructure 108 and updates a deployment plan based on customer feedback.

[0068] At 502, a task execution path associated with the highest probability of success in moving from the current environment 120 to the target environment 122 is calculated. For example, the deployment plan module 212 can perform statistical inference on the guidance information 224 based on whether other tasks have been successfully completed to calculate the probability of successfully completing the task. The task identification module 218 evaluates the various probabilities (e.g., individually and as a combination of probabilities built on top of each other) to determine the task execution path in the state diagram 222 that provides the highest probability of success.

[0069] At 504, a first subset of tasks along the task execution path is identified. In various examples, the number of tasks in the first subset is associated with a threshold number (e.g., one task, two tasks, three tasks, four tasks, etc.). Depending on the particular service and the particular segment, the threshold number can be pre-set to a small number of tasks (e.g., rather than a long and exhaustive list of hundreds of tasks) to reduce or eliminate the possibility that the client organization 104 becomes overwhelmed and disengages from the guided engagement session 116.

[0070] At 506 , the first subset of tasks is provided to the client organization 104 as part of the deployment plan.

[0071] At 508 , customer feedback is received indicating the status of the individual tasks (eg, successfully completed, incomplete or unsuccessfully completed, delayed, etc.). Figure 7 An example user interface is shown that may be used to provide customer feedback.

[0072] At 510, a second subset of tasks along the task execution path is identified. Similar to the first subset of tasks, the number of tasks in the first subset can be associated with a threshold number.

[0073] At 512 , the second subset of tasks is provided to the client organization 104 as part of the updated deployment plan.

[0074] Figure 6An example graphical user interface 600 is shown that a customer organization 104 and / or a service provider 102 can use to view a list of tasks to be completed and / or the status of individual tasks. A first portion 602 of the example graphical user interface 600 lists tasks (e.g., a first subset or a second subset) that are part of a deployment plan or an updated deployment plan. A second portion 604 of the example graphical user interface 600 indicates the status of the tasks listed in the first portion 602 (e.g., "completed," "stopped," "not started," etc.). In various implementations, the observation module 208 can determine that a "stopped" task is associated with an unsuccessful completion of the task (e.g., the customer encountered an error, the customer had difficulty completing the task, the customer took longer than the expected time to complete the task, etc.). A third portion 606 of the example graphical user interface 600 indicates the amount of time it took to complete the individual tasks. As described above, this information can be stored and aggregated for a particular segment and used to determine the expected amount of time 312 to complete a particular task. Finally, a fourth portion 608 of the example graphical user interface 600 indicates the difficulty of completing the task (e.g., "easy," "difficult," etc.). In various examples, the difficulty indication includes customer sentiment and can be used as a factor in calculating the probability of each node in the state diagram 222 .

[0075] Figure 7 An example graphical user interface 700 is shown that can be used by individual users of the client organization 104 and / or service provider 102 involved in the guided participation session to provide feedback on individual tasks. For example, at input window 702, the individual user can enter the status of the task (e.g., "successfully completed", "unsuccessfully completed", "in progress", etc.). At input window 704, the individual user can enter the amount of time it took to complete the individual task. At input window 706, the individual user can enter an indication of difficulty associated with the completion or non-completion of the task. This information can be stored in the database 300 in association with the service being guided and the particular segment.

[0076] Figure 8 800 for recalculating a task execution path based on customer feedback indicating that an individual task has not been successfully completed. Figure 5 Operations 508 and 510 in are implemented in association with each other.

[0077] At 802, it is determined that the status of the individual task indicates that it has not been successfully completed. In various examples, the status is determined based on customer feedback, and the unfinished task may be Figure 5As described above, based on customer feedback, task status module 220 can update nodes in state diagram 222 so that tasks attempted to be implemented by the customer organization are marked as "successfully completed" or "unsuccessfully completed".

[0078] At 804, the task execution paths associated with the highest probability of success are recalculated. For example, task identification module 218 can recalculate the probabilities and task execution paths within state diagram 222 after state diagram 222 is updated to indicate that the tasks were not successfully completed. Thus, the initial task execution paths calculated prior to selecting the first subset of tasks may be different than the subsequent task execution paths recalculated after receiving input indicating that the tasks were not successfully completed.

[0079] At 806, one or more replacement tasks along the recalculated task execution path are identified. In various examples, the one or more replacement tasks are Figure 5 The second subset of tasks identified in operation 510 of . Thus, in the event that the task execution path changes (eg, by recalculation), one or more alternative tasks are selected instead of other tasks along the task execution path that would have been selected if the task execution path had not been recalculated.

[0080] Figure 5 and / or Figure 8 The operation may be iterative such that the deployment plan module 212 may continually recommend a subset of tasks (e.g., a small number of tasks such as one task, two tasks, three tasks, four tasks, five tasks, etc.) based on input indicating successful or non-functional completion of previous tasks. This more refined and sophisticated assisted guidance approach based on continuous re-evaluation of the task execution paths with the highest probability of success results in higher customer satisfaction and engagement.

[0081] Fig. 9 A flow diagram of an example process 900 is shown that addresses errors that are common to multiple guided engagement sessions and identifies solutions to the errors.

[0082] At 902, a plurality of guided engagement sessions are monitored and / or information based on the monitoring is received. As described above, the observation module 208 is configured to monitor or receive information associated with the plurality of guided engagement sessions (e.g., completion of tasks, time to complete tasks, difficulty of completing tasks, etc.).

[0083] At 904, information associated with completion of tasks within the plurality of guided engagement sessions is stored.

[0084] At 906, errors common to tasks from at least some of the plurality of guided engagement sessions are determined. For example, errors may prevent or delay completion of the task (based on the evaluation of timing). Thus, in various examples, the error module 214 is configured to evaluate the stored information (e.g., the guided information 224) and determine that the plurality of client organizations were unsuccessful or delayed in completing the task. The error module 214 may analyze the stored information to determine common errors that delayed or prevented the client organizations from completing the task.

[0085] At 908, a solution to resolve the error is identified. For example, the solution module 216 can analyze the stored information and identify one or more solutions implemented by the client organization to resolve the error (eg, previous actions taken to resolve the error).

[0086] At 910, the associated one or more solutions are stored in association with the common error. In various examples, the errors and solutions can each be added to a supervised dataset for incremental learning (e.g., machine learning) and used to probabilistically determine the best next step (e.g., for a subsequent guided engagement session).

[0087] At 912, for each solution, a probability that the solution resolves the error is calculated. For example, a first solution may have been implemented to resolve common errors in a first number of guided engagement sessions (e.g., fifty out of a hundred or 50%), while a second solution may have been implemented to resolve common errors in a second number of guided engagement sessions (e.g., thirty out of a hundred or 30%).

[0088] At 914, the probabilities are stored in association with their corresponding solutions.

[0089] Fig.10 A flow chart of an example process 1000 for providing a solution in response to determining an occurrence of a runtime error in a current guided engagement session is shown.

[0090] At 1002, it is determined that a customer encountered a runtime error during implementation of a deployment plan. As an example, the error module 214 can detect a runtime error in response to determining that a current task has not been successfully completed within an expected amount of time to complete the task.

[0091] At 1004, runtime errors are mapped to corresponding errors common to previous boot engagement sessions.

[0092] At 1006, in response to determining that the customer has encountered a runtime error, solutions and their corresponding probabilities of resolution are provided to the customer organization. In various examples, the solution module 216 can provide a recommended solution (e.g., a solution with the highest probability of resolution). Moreover, the solution module 216 can provide the probability of resolution as a confidence rating.

[0093] Fig.11 A flow diagram of an example process 1100 is shown that computes task execution paths associated with the highest probability of success for directing services to a network computing infrastructure and updates a deployment plan based on automatic and continuous monitoring of individual task status.

[0094] At 1102, a task execution path associated with the highest probability of success in moving from the current environment 120 to the target environment 122 is calculated. For example, the deployment plan module 212 can perform statistical inference on the guidance information 224 to calculate the probability of successfully completing the task based on whether other tasks have been successfully completed. The task identification module 218 evaluates the various probabilities (e.g., individually and as a combination of probabilities built on top of each other) to determine the task execution path in the state diagram 222 that provides the highest probability of success.

[0095] At 1104 , a first subset of tasks along a task execution path is identified.

[0096] At 1106 , the first subset of tasks is provided to the client organization 104 as part of the deployment plan.

[0097] At 1108 , status of individual tasks in the first subset of tasks is automatically and continuously monitored and / or information associated with the monitoring is received.

[0098] At 1110, it is determined that an individual task in the first subset of tasks has not been completed within its expected amount of time to complete. Figure 5 In contrast to the explicit feedback provided by the customer in operation 508 , the input received here is based on automation and continuous monitoring.

[0099] At 1112 , the task execution path associated with the highest probability of success is recalculated.

[0100] At 1114, a second subset of tasks along the recomputed task execution path is identified. Similar to the first subset of tasks, the number of tasks in the first subset can be associated with a threshold number.

[0101] At 1116, the second subset of tasks is provided to the client organization 104 as part of the updated deployment plan. Thus, the stored guidance information 224 can be used to implement supervised learning and lead the autonomous guidance process based on the learning probability that effectively moves the client organization to full participation based on the completion of the selected next task.

[0102] Fig.12 A flow chart of an example process 1200 for automatically identifying and implementing a solution in response to determining an occurrence of a runtime error in a current guided engagement session is shown.

[0103] At 1202, it is determined that a customer encountered a runtime error during implementation of a deployment plan. As an example, the error module 214 can detect a runtime error in response to determining that a current task has not been successfully completed within an expected amount of time to complete the task.

[0104] At 1204, runtime errors are mapped to corresponding errors common to previous boot engagement sessions.

[0105] At 1206, the service provider 1206 takes action based on one of the solutions to automatically resolve the runtime error.

[0106] Of course, the environment and individual elements described herein may include many other logical, procedural, and physical components, of which those shown in the figures are merely examples relevant to the discussion herein.

[0107] The various techniques described herein are assumed in the given examples to be implemented in the general context of computer-executable instructions or software (e.g., program modules) stored in a computer-readable storage device and executed by one or more processors of computers or other devices such as those shown in the accompanying drawings. Typically, program modules include routines, programs, objects, components, data structures, etc., and define operating logic for performing specific tasks or implementing specific abstract data types.

[0108] Other architectures may be used to implement the described functionality and are intended to be within the scope of the present disclosure.In addition, although specific allocations of responsibilities are defined above for purposes of discussion, the various functions and responsibilities may be allocated and divided in different ways depending on the circumstances.

[0109] Similarly, software can be stored and distributed in various ways and using different means, and the above-mentioned specific software storage and execution configuration can be changed in many different ways. Therefore, the software implementing the above-mentioned technology can be distributed on various types of computer-readable media, not limited to the form of the memory specifically described.

[0110] Sample Clauses

[0111] Example A, one or more devices include: one or more processors; and a memory having computer executable instructions stored thereon, the computer executable instructions, when executed by the one or more processors, causing the one or more devices to: monitor multiple boot engagement sessions, wherein individual boot engagement sessions include tasks for moving at least a portion of a service from a customer-managed computing infrastructure to a network computing infrastructure; store boot information associated with completion of the tasks of the multiple boot engagement sessions in a database and based at least in part on the monitoring; determine errors common to tasks from at least some of the multiple boot engagement sessions, wherein the errors prevent or delay completion of the tasks; identify one or more solutions that individually have the potential to resolve the errors based at least in part on the boot information; and store the one or more solutions in the database and in association with the errors.

[0112] Example B, one or more devices of Example A, wherein the computer-executable instructions further cause the one or more devices to: determine that a customer organization has encountered a runtime error associated with a current task of a guided engagement session, wherein the runtime error delays or prevents completion of the current task; map the runtime error to at least some of the common errors in the multiple guided engagement sessions stored in the database; and in response to determining that the customer organization has encountered a runtime error, provide the customer organization with one or more solutions and corresponding one or more resolution probabilities.

[0113] Example C, the one or more devices of Example B, wherein the computer-executable instructions further cause the one or more devices to recommend a recommended solution of the one or more solutions.

[0114] One or more devices of Example D, Example B, or Example C, wherein the computer executable instructions further cause the one or more devices to: determine that a task was not successfully completed within an expected amount of time to complete the task; and determine that the client organization has encountered a runtime error in response to determining that the task was not successfully completed within the expected amount of time to complete the task.

[0115] Example E, one or more devices of any of Examples A to D, wherein the computer executable instructions further cause the one or more devices to: calculate a resolution probability for a separate solution of one or more solutions; store the corresponding resolution probabilities in a database; and provide the corresponding resolution probabilities as confidence ratings.

[0116] Example F, one or more devices of any one of Examples A to E, wherein the error is specific to a particular segment of a plurality of different segments based on a size of a customer organization, wherein the guidance information is stored in a database for the particular segment of the plurality of different segments.

[0117] Example G, one or more devices of any of Examples A to F, wherein at least one of the one or more solutions includes instructions to interact with a third party system to enable completion of a task.

[0118] Example H, a method, comprising: monitoring multiple bootstrap engagement sessions, wherein individual bootstrap engagement sessions include tasks of moving at least a portion of a service from a customer-managed computing infrastructure to a network computing infrastructure; storing bootstrap information associated with completing the tasks of the multiple bootstrap engagement sessions in a database and based at least in part on the monitoring; determining, by one or more processors, errors common to tasks from at least some of the multiple bootstrap engagement sessions, wherein the errors prevent or delay completion of the tasks; identifying one or more solutions that individually have the potential to resolve the errors based at least in part on the bootstrap information; and storing the one or more solutions in the database and in association with the errors.

[0119] The methods of Example I and Example H also include: determining that a customer organization has encountered a runtime error associated with a current task of a current boot participation session, wherein the runtime error delays or prevents completion of the current task; mapping the runtime error to errors stored in the database that are common to at least some of the multiple boot participation sessions; and providing the one or more solutions to the customer organization in response to determining that the customer organization has encountered a runtime error.

[0120] Example J, the method of Example I also includes recommending a recommended solution of one or more solutions.

[0121] The method of Example K, Example I or Example J also includes: determining that the task was not successfully completed within the expected amount of time to complete the task; and determining that the client organization has encountered a runtime error in response to determining that the task was not successfully completed within the expected amount of time to complete the task.

[0122] The method described in Example L, Examples H to K, further includes: calculating a solution probability for a separate solution among the one or more solutions; storing the corresponding solution probability in the database; and providing the corresponding solution probability as a confidence rating.

[0123] Example M, the method of any of Examples H to L, wherein the error is specific to a particular segment of a plurality of different segments based on a size of a customer organization, wherein the guidance information is stored in the database for the particular segment of the plurality of different segments.

[0124] Example N, the method of any of Examples H to M, wherein at least one of the one or more solutions includes instructions to interact with a third party system to enable completion of a task.

[0125] Example O: One or more computer-readable storage media storing computer-executable instructions that, when executed by a processor, cause a device to: monitor a plurality of bootstrap engagement sessions, wherein individual bootstrap engagement sessions include a task of moving at least a portion of a service from a customer-managed computing infrastructure to a network computing infrastructure; store in a database and based at least in part on the monitoring bootstrap information associated with completion of the tasks of the plurality of bootstrap engagement sessions; determine an error common to the tasks from at least some of the plurality of bootstrap engagement sessions, wherein the error prevents or delays completion of the task; identify, based at least in part on the bootstrap information, one or more solutions that individually have the potential to resolve the error; and store the one or more solutions in the database and in association with the error.

[0126] Example P, one or more computer-readable storage media of Example O, wherein the computer-executable instructions further cause the device to: determine that a client organization has encountered a runtime error associated with a current task of a current boot participation session, wherein the runtime error delays or prevents completion of the current task; map the runtime error to errors stored in the database that are common to at least some of the multiple boot participation sessions; and provide the one or more solutions in response to determining that the client organization has encountered a runtime error.

[0127] Example Q, one or more computer-readable storage media of example P, wherein the computer-executable instructions further cause the device to recommend a recommended solution of the one or more solutions.

[0128] One or more computer-readable storage media of Example R, Example P, or Example Q, wherein the computer-executable instructions further cause the device to: determine that a task was not successfully completed within an expected amount of time to complete the task; and determine that the client organization has encountered a runtime error in response to determining that the task was not successfully completed within the expected amount of time to complete the task.

[0129] Example S, one or more computer-readable storage media of any one of Examples O to R, wherein the computer-executable instructions further cause the device to: calculate a solution probability for a separate solution among the one or more solutions; store the corresponding solution probability in the database; and provide the corresponding solution probability as a confidence rating.

[0130] Example T, one or more computer-readable storage media of any of Examples O to S, wherein the error is specific to a particular segment among a plurality of different segments based on a size of a customer organization, wherein the guidance information is stored in the database for the particular segment among the plurality of different segments.

[0131] in conclusion

[0132] Finally, although various implementations may have been described using language specific to structural features and / or methodological acts, it should be understood that the described subject matter is not necessarily limited to the specific features or acts described. Rather, the specific features and acts are disclosed as example forms of implementing the claimed subject matter.

Claims

1. One or more devices for service bootstrapping, including: one or more processors; as well as a memory having computer executable instructions stored thereon that, when executed by the one or more processors, cause the one or more devices to: monitoring a bootstrap engagement session, the bootstrap engagement session comprising a task of moving at least a portion of a service from a customer-managed computing infrastructure to a network computing infrastructure; determining errors that prevent or delay completion of individual ones of the tasks; identifying one or more solutions that can be individually implemented to resolve the error; as well as Action is taken to resolve the error by implementing at least one of the one or more solutions.

2. One or more devices for service bootstrapping as claimed in claim 1, wherein: The computer executable instructions further cause the one or more devices to: A status of the individual task is displayed on a graphical user interface, the status indicating that the error is preventing or delaying completion of the individual task.

3. One or more devices for service bootstrapping as claimed in claim 1, wherein: The computer executable instructions further cause the one or more devices to: A solution probability associated with the at least one solution is provided.

4. One or more devices for service bootstrapping as claimed in claim 1, wherein: The computer executable instructions further cause the one or more devices to: The at least one solution of the one or more solutions is recommended.

5. One or more devices for service bootstrapping as claimed in claim 1, wherein: The individual tasks are associated with an expected amount of time to complete, and the computer-executable instructions further cause the one or more devices to: A determination is made that the client organization has encountered the error in response to determining that the individual task has not been successfully completed within the expected amount of time for completion.

6. One or more devices for service bootstrapping as claimed in claim 1, wherein: The error is specific to a particular segment of a plurality of different segments based on a size of a client organization, and the one or more solutions are stored in a database for the particular segment of the plurality of different segments.

7. One or more devices for service bootstrapping as claimed in claim 1, wherein: The at least one solution of the one or more solutions includes instructions for interacting with a third party system to enable completion of the individual task.

8. A method for service bootstrapping, comprising: monitoring a bootstrap engagement session, the bootstrap engagement session comprising a task of moving at least a portion of a service from a customer-managed computing infrastructure to a network computing infrastructure; determining errors that prevent or delay completion of individual ones of the tasks; identifying, by one or more processors, one or more solutions that can be individually implemented to resolve the error; as well as Action is taken to resolve the error by implementing at least one of the one or more solutions.

9. The method of claim 8, further comprising: A status of the individual task is displayed on a graphical user interface, the status indicating that the error is preventing or delaying completion of the individual task.

10. The method of claim 8, further comprising: A solution probability associated with the at least one solution is provided.

11. The method of claim 8, further comprising: The at least one solution of the one or more solutions is recommended.

12. The method of claim 8, wherein: The individual tasks are associated with an expected amount of time to complete, and the method further comprises: A determination is made that the client organization has encountered the error in response to determining that the individual task has not been successfully completed within the expected amount of time for completion.

13. The method of claim 8, wherein: The error is specific to a particular segment of a plurality of different segments based on a size of a client organization, and the one or more solutions are stored in a database for the particular segment of the plurality of different segments.

14. The method of claim 8, wherein: The at least one solution of the one or more solutions includes instructions for interacting with a third party system to enable completion of the individual task.

15. One or more devices for service bootstrapping, including: one or more processors; as well as a memory having computer executable instructions stored thereon that, when executed by the one or more processors, cause the one or more devices to: monitoring a plurality of guided engagement sessions over a period of time, wherein individual guided engagement sessions of the plurality of guided engagement sessions include a task of moving at least a portion of a service from a customer-managed computing infrastructure to a network computing infrastructure; storing, in a database and as a result of said monitoring, guidance information associated with completion of tasks for said plurality of guided engagement sessions; determining, by the one or more processors, errors that occurred in at least some of the plurality of guided engagement sessions, wherein the errors prevented or delayed completion of a common task; Based at least in part on the guidance information, identifying one or more solutions that are individually implemented to resolve the error; and The one or more solutions are stored in the database and associated with the error.

16. One or more devices for service bootstrapping as claimed in claim 15, wherein: The one or more solutions can be used to resolve the error in future guided engagement sessions.

17. One or more devices for service bootstrapping as claimed in claim 15, wherein: The computer executable instructions further cause the one or more devices to: calculating a solution probability for each of the one or more solutions; and The resolution probability is stored in the database.

18. The one or more devices for service bootstrapping of claim 15, wherein: The error is specific to a particular segment of a plurality of different segments based on a size of a customer organization, wherein the guidance information is stored in the database for the particular segment of the plurality of different segments.

19. The one or more devices for service bootstrapping of claim 15, wherein: The computer executable instructions further cause the one or more devices to: Based at least in part on the monitoring, an expected amount of time to complete the common task is determined.

20. The one or more devices for service bootstrapping of claim 15, wherein: At least one of the one or more solutions includes instructions to interact with a third party system to enable completion of the common task.

21. A system for service bootstrapping, comprising: one or more processors; as well as a memory having computer executable instructions stored thereon that, when executed by the one or more processors, cause the system to: monitoring a directed engagement session, the directed engagement session comprising a task of moving at least a portion of a service from a customer-managed resource to a network resource; detecting an error based on determining that an individual task was not successfully completed within an expected amount of time to complete the individual task, wherein the expected amount of time to complete the individual task is calculated as an average of actual times taken to complete the individual task in previous boot sessions; identifying one or more solutions that have been implemented in the previous boot session to resolve the error; and Action is taken to resolve the error by implementing at least one of the one or more solutions.

22. The system of claim 21, wherein: The computer executable instructions further cause the system to: A status of the individual task is displayed on a graphical user interface, the status indicating that the error is preventing or delaying completion of the individual task.

23. The system of claim 21, wherein: The computer executable instructions further cause the system to: For each of the one or more solutions, a solution probability is calculated.

24. The system of claim 23, wherein: The at least one solution is selected from the one or more solutions based on having a highest probability of being solved.

25. The system of claim 21, wherein: The computer executable instructions further cause the system to: The at least one solution of the one or more solutions is recommended.

26. The system of claim 21, wherein: The error is specific to a particular segment of a plurality of different segments based on a size of a client organization, and the one or more solutions are stored in a database for the particular segment of the plurality of different segments.

27. The system of claim 21, wherein: The at least one solution of the one or more solutions includes instructions for interacting with a third party system to enable completion of the individual task.

28. A method for service bootstrapping, comprising: monitoring a directed engagement session, the directed engagement session comprising a task of moving at least a portion of a service from a customer-managed resource to a network resource; detecting an error based on determining that an individual task was not successfully completed within an expected amount of time to complete the individual task, wherein the expected amount of time to complete the individual task is calculated as an average of actual times taken to complete the individual task in previous boot sessions; identifying, by one or more processors, one or more solutions that have been implemented in the previous boot session to resolve the error; and Action is taken to resolve the error by implementing at least one of the one or more solutions.

29. The method of claim 28, further comprising: A status of the individual task is displayed on a graphical user interface, the status indicating that the error is preventing or delaying completion of the individual task.

30. The method of claim 28, further comprising: For each of the one or more solutions, a solution probability is calculated.

31. The method of claim 30, wherein: The at least one solution is selected from the one or more solutions based on having a highest probability of being solved.

32. The method of claim 28, further comprising: The at least one solution of the one or more solutions is recommended.

33. The method of claim 28, wherein: The error is specific to a particular segment of a plurality of different segments based on a size of a client organization, and the one or more solutions are stored in a database for the particular segment of the plurality of different segments.

34. The method of claim 28, wherein: The at least one solution of the one or more solutions includes instructions for interacting with a third party system to enable completion of the individual task.

35. One or more non-transitory computer-readable storage media storing computer-executable instructions that, when executed by one or more processors, cause a system to perform operations comprising: monitoring a directed engagement session, the directed engagement session comprising a task of moving at least a portion of a service from a customer-managed resource to a network resource; An error is detected based on determining that an individual task is not successfully completed within an expected amount of time to complete the individual task, wherein: The expected amount of time to complete the individual tasks is calculated as an average of actual times taken to complete the individual tasks in previous guided sessions; identifying one or more solutions that have been implemented in the previous boot session to resolve the error; as well as Action is taken to resolve the error by implementing at least one of the one or more solutions.

36. The one or more non-transitory computer-readable storage media of claim 35, wherein: The operations also include: A status of the individual task is displayed on a graphical user interface, the status indicating that the error is preventing or delaying completion of the individual task.

37. The one or more non-transitory computer-readable storage media of claim 35, wherein: The operations also include: For each of the one or more solutions, a solution probability is calculated.

38. The one or more non-transitory computer-readable storage media of claim 37, wherein: The at least one solution is selected from the one or more solutions based on having a highest probability of being solved.

39. The one or more non-transitory computer-readable storage media of claim 35, wherein: The error is specific to a particular segment of a plurality of different segments based on a size of a client organization, and the one or more solutions are stored in a database for the particular segment of the plurality of different segments.

40. The one or more non-transitory computer-readable storage media of claim 35, wherein: The at least one solution of the one or more solutions includes instructions for interacting with a third party system to enable completion of the individual task.

Images