them for a while. Such proactive chatbots require a more complex technical setup where bots periodically “wake up” to reach out to the customer. In the travel context, the outreach could be triggered by specific events, such as upcoming flights, changes in travel advisories, or be customer-specific behaviors, such as checking in with a customer who usually books specific upgrades. Technical considerations. Building a proactive chatbot requires integrating calendar systems, monitoring tools, and customer relationship management (CRM) systems. The challenge lies in designing a system that balances proactive engagement without becoming intrusive, potentially requiring advanced user preference management and context-awareness capabilities. A proactive chatbot is generally not possible without knowing the user (dimension 2) and might often require additional data from an external system. In most cases, this requires system integration and thus additional development resources. Lastly, the medium of outreach can play a big role — nudging via email might be less effective than via a text message or app notification, which would require further development resources to design a mobile app. Data and privacy concerns arise in these cases and should be carefully considered and addressed to ensure user trust and compliance. Dimension 4: Static vs. Dynamic Does the bot learn about a user or a user population over time? A static bot operates with a fixed set of rules or knowledge. For a given question, a static bot always provides the same answer. This might, however, miss important opportunities. For example, an investor who is requesting her tax documents likely has very different preferences in April (when most Americans file their taxes) compared to November. A dynamic chatbot adapts its behavior based on external factors or evolving data. The choice between static and dynamic bots influences how the bot adapts over time and depending on the user. A static bot uses a system prompt and potentially auxiliary systems, such as RAG, to provide information. While it can refer to previous conversations if those are preserved (see dimension 2), it has no representation of time and its influence on customer needs and changes in the surrounding world. Technical considerations. A simple way to make the chatbot dynamic is by updating the system prompt periodically to include new knowledge, such as the time to the next Tax Day. An even more dynamic approach could involve retrieving the investor’s personal tax schedule. Just as discussed previously, this would require access to additional databases, such as the organization’s CRM system. In addition to learning more about an individual customer over the course of a longer relationship, we can also imagine chatbots learning from other customers (population-level learning, see Siggelkow and Terwiesch 2019) and using this knowledge to improve the quality of the support. In this case, rather than using an existing frontier model, the organization would train its own model based on the incoming support requests and their resolutions (“we noticed that customers like you who faced similar problems benefited from doing xyz").