> For the complete documentation index, see [llms.txt](https://en.help.firstline.cc/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://en.help.firstline.cc/feature/chatbot/scenario/example/create-a-reusable-main-menu.md). # Create a reusable main menu Explains how to split the trigger entry and the main menu into two separate scripts, allowing customers to return directly to the main menu from different flows without entering a message again. When designing a conversation script, a common scenario is that after a customer enters a certain issue flow, they want to use “Back to Main Menu” to see the original menu again. For example: 1. The customer enters the “Return Issue” script. 2. After the query is completed, the screen provides a “Back to Main Menu” button. 3. After clicking it, the customer expects the system to immediately show the main menu items again, such as “Order Inquiry,” “Return Issue,” and “Contact Support.” The most common problem in this kind of scenario is usually not “whether the transfer to another script was set up,” but rather**the linked script is still waiting for an event at the beginning**. For example, the first node of the original main script is “wait for customer message.” Even if you use “go to another script” from the “Return Issue” flow to return to this script, the process will still stop at the event node and will only continue after the customer enters a message again. Therefore, if the main menu needs to support both “a customer’s first inquiry” and “direct return from other flows,” it is recommended not to place the event entry and the main menu content in the same script, but instead**split them into two separate general scripts**. {% hint style="info" %} It is recommended to create two different scripts: 1. **Entry script**: only responsible for receiving the customer’s first inquiry, keywords, or other events. 2. **Main menu script**: another separate script responsible for actually sending the main menu content, with no event at the beginning that requires waiting for customer action. After the event is triggered, the entry script then connects to the main menu script via “go to another script.” {% endhint %} The structure can be understood as: ``` Script A: Entry script └─ Wait for customer message / determine keyword └─ Go to another script → “Main menu script” Script B: Main menu script ├─ Send main menu message ├─ Order inquiry ├─ Return issue └─ Contact support ``` Here, the “entry script” and the “main menu script” are**two different conversation scripts**, not two sections within the same script. Later, when other feature scripts need to “return to the main menu,” they do not need to go back to the entry script; instead, they can directly go to the same “main menu script.” ``` Script C: Return issue └─ Issue handling completed └─ Go to another script → “Main menu script” ``` In this way, whether the customer is making a first inquiry or returning from another flow, they will eventually enter the same main menu script, but only the first inquiry needs to pass through an event node. ## Method 1: Directly go to a separate main menu script If “return to main menu” means the current flow has already ended, the most direct approach is to create a**separate “main menu script”**and let other scripts connect to it directly via “go to another script.” For example, create three scripts in total: ``` Script A: Entry script └─ Customer sends message └─ Go to another script → “Main menu script” Script B: Main menu script ├─ Send menu ├─ Order inquiry ├─ Return issue └─ Contact support Script C: Return issue └─ Issue handling completed └─ Go to another script → “Main menu script” ``` The most important point is:**Do not place event nodes such as “wait for customer message” at the beginning of Script B, the “main menu script.”** If the main menu script still begins with an event, even if Script A or Script C successfully goes to Script B, the process will still stop, and the customer will have to enter a message again. Therefore, it is recommended that the main menu script start directly with nodes that can execute immediately, such as “send message” or “send options.” ### Suitable scenarios * After completing a certain feature flow, you want to display the full main menu directly. * There is no need to return to the original feature script to continue execution. * You want multiple feature scripts to share the same main menu. {% hint style="info" %} The “entry script” mainly handles when to start; the “main menu script” handles what to display after starting. After separating them into independent scripts, other feature scripts can skip the entry event and go directly to the main menu script. {% endhint %}
## Method 2: Split reusable small flows into module scripts If what needs to be reused is not the entire main menu, but a small shared flow, you can consider using a “module script.” For example, if multiple scripts all need the same: * identity verification * order inquiry * data confirmation * shared prompt messages you can create a separate module script for different general scripts to call. ``` Script C: Return issue ├─ Return explanation ├─ Go to module → “Data confirmation” └─ Continue with the follow-up return process ``` Module scripts follow a similar principle: if you want the content to execute immediately after calling the module, the module should not start by waiting for a new customer event. However,**it is not recommended to use a complete main menu with a lot of branching directly as a module**. If the main menu needs to go to other feature scripts, transfer to a human agent, or handle the main routing, it is usually better to create a separate general “main menu script.” ### Suitable scenarios * The same small flow needs to be reused in multiple scripts. * After executing the shared flow, you still need to return to the original script and continue the following steps. * You want to reduce repetitive setup and future maintenance costs. {% hint style="warning" %} A module script is not the same as a main menu script. Some operations in a module are restricted, such as using “go to another script,” transferring to a human agent, or calling another module again. For a complete main menu, it is generally recommended to create a separate general script. {% endhint %} ## Method 3: Trigger the entry script with a button message, then go to the main menu script If the existing design already relies on customers entering text such as “main menu” or “back to main menu” to trigger the flow, you can keep this approach. For example: ``` Button label: Back to Main Menu Actually sent: Back to Main Menu ``` After the customer clicks it, a new customer message will be sent, which can trigger the original event listening for “Back to Main Menu.” But it is still recommended to split it into two scripts: ``` Customer sends “Back to Main Menu” ↓ Script A: Entry script └─ Determine the “Back to Main Menu” keyword └─ Go to another script → “Main menu script” Script B: Main menu script └─ Send the main menu immediately ``` This way, both entry methods can be supported: ``` Method 1: The customer actively types or uses a button to send text ↓ Entry script ↓ Main menu script Method 2: The customer is already in another feature script ↓ Go directly to the main menu script ``` The second case does not need to go through the entry script again, because the customer is already in the flow and does not need to create another message event to display the main menu. ### Suitable scenarios * The existing system already uses keyword triggers extensively. * You still want customers to be able to type text such as “main menu” to open the menu themselves. * At the same time, you also want other feature scripts to be able to return directly to the same main menu. {% hint style="warning" %} Different messaging channels support different button behaviors. If you want a button click to automatically send the specified text, please first confirm whether the current channel and message type support the “send message” behavior. {% endhint %} ## Why is it recommended to split into two scripts? If “waiting for customer events” and “displaying the main menu” are placed in the same script, then every time this script is revisited by another flow, it may stop again at the event node. After splitting into two scripts, the responsibilities will be clearer: | Script | Main purpose | Can there be an event at the beginning? | | -------------------- | -------------------------------------------------------------------------- | --------------------------------------- | | **Entry script** | Receive first inquiry, keyword, or specified customer message | Yes | | **Main menu script** | Actually send the main menu, shared by the entry and other feature scripts | Not recommended | The complete relationship is as follows: ``` Script A: Entry script ├─ Customer first inquiry ├─ Customer enters “main menu” └─ Customer uses a button to send “Back to Main Menu” ↓ Go to another script ↓ Script B: Main menu script ├─ Order inquiry ├─ Return issue └─ Contact support ↑ │ Scripts C, D, E: various feature scripts When a return is needed, directly go to Script B ``` Therefore, the “main menu script” can be viewed as the destination that all flows go to together; the “entry script” is just one of the sources that leads to it. ## Which method should be chosen? | Requirement | Recommended method | | -------------------------------------------------------------------- | --------------------------------------------------------------------------------------- | | After other feature flows end, directly return to the full main menu | Create an independent **Main menu script**, and go directly via “go to another script” | | Multiple scripts only need to share a small part of the process | Use **module script** | | Keep the “main menu” keyword or button message trigger | Let **Entry script** receive the event, then go to the independent **Main menu script** | If the existing architecture already relies on keyword triggers, there is no need to redo everything. You can keep the script that originally handles event reception, move the part that actually displays the menu into a new “main menu script,” and then have both the original entry script and other feature scripts go to this new script. ## Design recommendations As scripts become more complex, you can separate different responsibilities for management: * **Entry script (general script)**: a separate script responsible for the customer’s first inquiry, keyword, or other event triggers, and uses “go to another script” after the conditions are met. * **Main menu script (general script)**: another separate script that actually sends the main menu and handles the main service routing; it no longer waits for a new customer event at the beginning. * **Feature script (general script)**: for example, return, order, membership, and other complete service flows; when a return is needed, directly go to the “main menu script.” * **module script**: place small operations that are reused by multiple flows. In this way, “how to trigger” and “what to execute after triggering” are handled by different scripts. When new services are added or the main menu is adjusted later, all entry and feature flows can also share the same main menu script.