# Real-world scenarios ## Overview This article walks through two practical scenarios that illustrate how the Knowledge Manager supports field engineers in the flow of work. The first follows a technician resolving a fault using the Knowledge Manager through Microsoft Teams, covering the full interaction from initial question through to job closure and knowledge capture. The second illustrates what happens when a question cannot be fully answered, showing how the system handles gaps rather than returning unreliable guidance. ### Scenario 1: Field Fault Resolution via Teams This scenario follows a field service engineer encountering a fault code on site and using the Knowledge Manager to resolve it, without searching across multiple systems, calling a senior colleague, or leaving the issue partially resolved. #### Start of Day The engineer opens their job in the mobile app. Before they arrive on site, the Knowledge Manager has already assembled a contextual knowledge pack based on the asset configuration, service history, and any relevant manuals, so the engineer arrives with relevant context already available rather than starting from scratch on site. #### Fault Encountered A fault code appears that the engineer hasn't seen recently on this configuration. Rather than opening multiple systems to search for relevant procedures, the engineer submits a question in natural language through Microsoft Teams, describing the scenario they're dealing with. #### Knowledge Manager Responds The Knowledge Manager interprets the intent behind the question, identifies the asset type and configuration from the job context, and searches all connected knowledge sources simultaneously: manuals, historical service records, prior case resolutions, and engineering bulletins. Within seconds, a response comes back directly in Teams with: * The most relevant diagnostic steps for that specific asset configuration * Citations showing exactly which sources the guidance came from * Links to supporting documentation for reference The engineer does not need to open any other system. The guidance is specific to the asset they are working on, not a generic procedure that requires interpretation. #### Follow-Up and Clarification The engineer follows the diagnostic steps and adds some additional context about what they're observing. The Knowledge Manager responds with further detail, continuing the conversation naturally and maintaining the context of the original question throughout. Each response can be rated with a thumbs up or thumbs down. This feedback is captured automatically and contributes to improving future responses for similar queries. #### Issue Resolved The engineer follows the recommended steps and resolves the issue on the first visit. The interaction has replaced what would previously have been 15 to 20 minutes of searching across multiple systems, a phone call to a senior technician, and a potential follow-up visit due to incomplete or generic guidance. #### Job Notes Generated When the job is closed, the Knowledge Manager can generate a set of job notes from the interaction, structured from the conversation, the guidance used, and the outcome. The engineer reviews and submits them. These notes contribute to the knowledge base, ensuring that the resolution is captured in a reusable form rather than buried in free-text. ### Scenario 2: Handling a Knowledge Gap This scenario covers what happens when a question arrives that the Knowledge Manager cannot answer with high confidence, for example, a query about a non-standard configuration for which documentation is incomplete or missing. #### Question Submitted An engineer submits a question about safety or configuration steps for a non-standard installation. The Knowledge Manager interprets the query and begins searching connected sources. #### Low Confidence Detected The system finds some relevant content but identifies that the available guidance has low confidence for this specific configuration, perhaps because documentation is partial, conflicting, or has not been updated to reflect recent equipment changes. Rather than returning the low-confidence guidance as if it were reliable, the Knowledge Manager does two things: 1. Requests additional context from the engineer, asking a targeted follow-up question to narrow the scenario before returning guidance. This ensures that if a reliable answer exists, it can be retrieved more precisely. 2. Flags the gap in the background, registering that this configuration has been queried and that the available knowledge is insufficient to answer it with confidence. #### Guidance Returned with Appropriate Signals If a high-confidence answer can be assembled after clarification, it is returned with citations and confidence indicators. If the gap is genuine and cannot be resolved from current sources, the Knowledge Manager communicates this clearly rather than returning unreliable guidance, and escalation paths are available for cases that require senior review. #### Gap Triggers Content Action The flagged gap is logged automatically. If the same configuration is queried repeatedly without a satisfactory answer, the Knowledge Manager surfaces this pattern for review, identifying it as a knowledge gap that needs to be addressed. It can generate a draft knowledge article based on the interaction context, which is routed through a human approval process before being published back into the knowledge base. Over time, this means the knowledge base evolves based on what engineers are actually encountering in the field, not just what was documented when the system was first set up. ### What These Scenarios Illustrate **Knowledge is delivered in the flow of work.** Engineers don't leave Teams to find answers. The entire interaction, question, guidance, follow-up, job notes, happens in the same interface they're already using. **Guidance is specific, not generic.** The Knowledge Manager uses asset ID, configuration, service history, and job context to return steps that apply to the exact situation. Generic documentation that might not apply is filtered out. **Citations make trust explicit.** Every response includes sources, so engineers can see where the guidance comes from and assess its authority. Confidence indicators make the reliability of each answer visible. **The system asks rather than guesses.** When context is missing or confidence is low, the Knowledge Manager asks a targeted follow-up question rather than returning uncertain guidance. This is particularly important in safety-sensitive environments where acting on incorrect information carries real risk. **Gaps are captured, not ignored.** When knowledge doesn't exist or is insufficient, the system flags it automatically rather than letting the gap persist. Over time this drives continuous improvement of the knowledge base from real field demand. **Resolved jobs feed future answers.** Knowledge generated through interactions, job notes, resolution steps, workarounds, is structured and routed for review rather than left in free-text notes. This turns individual resolutions into reusable organizational knowledge. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://kb.theloops.io/digitalworkers/ifs-loops-digital-workers/digital-worker-guides/knowledge-manager/core-concepts/real-world-scenarios.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.