Electronic Supplementary Materials

Appendices A. Session Demo (Illustration of session 1) A.1 Preparation of the elicitation interview Context: Business process analysts prepare the interview canvas that will guide the semi-structured discussion conducted by the conversational agent. They have the option of adding an “expected output” if they want the conversational agent to specifically verify that domain experts mention these elements (See B.1 Socialization). … A.2 Socialization: Elicitation session Context: The domain expert receives a link and login credentials to connect to a session guided by a conversational agent. They can provide information in writing or verbally by answering the conversational agent's questions. The domain expert can skip the question by using pre-designed answers if they deem it useful. A.3 Externalization: Formalization of process knowledge Context: At the end of the session, business process analysts can view the results generated by the multiagent system. In particular, they can download the generated .bpmn file. Context: .bpmn graphic generated by the tool following session 1. The layout has been modified to improve the clarity of the illustration in .png format. (Model presented in the paper and in supplementary materials (in .bpmn format)). … B. Design choices Here is a brief description of the design choices that could influence our results. B.1 Socialization This section outlines the complete set of actions undertaken by the agents in the continuous supervision of the interaction between the domain expert and the conversational agent responsible for knowledge elicitation (i.e., Elicitor). Fig. 6 Conversation monitoring using semi-guided interviews. Inspired by Hu et al. (2024) Willingness or Ability Check: The first test aims to assess the willingness or ability of the domain expert to respond to a given question. If the agent determines that the user is either unwilling or unable to provide an answer, it proceeds to the next question without generating a follow-up, in order to preserve the domain expert’s user experience. In the two images below, we can observe that the domain expert expresses—in two different ways—that they do not have an answer to the questions selected by the tool. In such cases, as indicated by the code trace logs (see below), the test returns a positive result, meaning that no follow-up question should be generated. Expected output follow-up: The second test is designed to emphasize the key elements, from the analyst’s perspective, that are expected during information gathering (i.e., expected outputs). This test focuses on assessing whether these essential elements are present in the domain expert’s response. The images below illustrate a case in which the details provided by the domain expert are insufficient. In this example, the threshold is set at 4 out of 10. When the score falls below this threshold, a followup question is automatically generated. No follow up question No follow up question Insufficient information provided: a follow-up question is generated. Standard follow-up : When no expected outputs are defined or when the information provided sufficiently addresses the targeted points, we proceed to a different type of test. This test evaluates the semantic quality and coherence of the user's response within the context of the ongoing conversation. Similar to the previous test, a score ranging from 1 to 10 is returned. If the score exceeds the predefined threshold (set to 4 in our case), the information is considered satisfactory (info ok = 0). Otherwise, a follow-up question is generated to clarify the inconsistencies (info ko = 1). No Follow-up: In the final case, the information collected is deemed sufficient, and no follow-up question is generated. The quality of the provided information is insufficient: a follow-up question is generated.