These days customers want more than individual interactions with applications. They want applications to do more of the work - "automatically". "Automatically" is the word our customers use when they want an application to do more of the heavy lifting. Sometimes I translate this as -- "I don't even want to click a button can't the application just tell me what is going on?"

As an example of this, my thinking moves to banking. Sure I could log on to the bank's website or mobile app and look at my balances but why should I have to take that time out of my day? Why can't the banking application send me a notification when a transaction clears and my bank balance is updated? Send me the transaction amount, the check number and the new balance. That way I know instantly what is going on and I don't have to do anything (e.g. log into an app).

For the applications Cyberwolf Software codes, we are now getting more and more of these type of requests. In one of our operations SaaS applications, there is a time delay between when the order goes in and when the work actually occurs. This is event based work that could occur months later. Our customer requested an automatic notification (handled by a bot or agent) that would notify their customer three weeks prior to their upcoming order; requesting any missing information on the order to insure a smooth and successful execution of the order.

Cyberwolf Software developed a bot (or agent) that runs nightly to notify the customers of their upcoming orders. What's interesting is how many examples our developers started to consider as we coded this agent. Some examples of this include:

• Notify a Power User or Administrator when configuration or supporting data in an application was missing.
• User requested notifications by type. Similar to a Publisher/Subscriber Observer pattern with a customized set of types
• Auto updates to balances of any tracked numbers and notifications of same.
• User selections of automatic reporting. Similar to the requested notifications by type but this would be full reports.

The above examples are just a few that our coders brainstormed.

However, it is also useful to play devil's advocate when developing new functionality. Contrary questions that arose:

• Information Overload - How much notification is too much notification?
• Information Priority - How do you specify priority on notifications? All notifications don't have the same value.
• Information Action - Do you only "notify" inforamtion that requires immediate or near-term action?
• Information Balance - How often do you "notify"? How many repeats of same notification?
• Notification Opt-out - Should users' decide the level of notification? Again, how much is too much?
• Meta-data to Admin - Should an Admin get notified as well or see a report to show the software agent operations?

The current implementation of the "Order Notification Bot" allows a user to opt-out or unsubscribe from the notification. However, it is controlled by an Administrator and not the end recipient directly. This was intentional and part of the requirements specified by our customer.

Finally, with the advances in A.I. and machine learning, will a future feature request from our customer be -- Can you build a bot that reads the Auto Notifications Bots information and take appropriate action without me?