Information Overload! Think Twice Before Flipping The Switch On Alert Management

Lately I’ve been really focused on process automation -- specifically, how software can help but also potentially cripple cycle times. When it comes to enterprise applications, my strong view is that event and alert management solutions are two of the most critical components to achieving success.

Services Procurement (aka Vendor Management Systems) are no exception to this rule and since we are currently in the process of writing a Forrester Wave™ evaluation on this topic, I thought I’d share a few thoughts on what companies should look for in the context of these tools. Let’s start with a snapshot of a recent interview I conducted with a VMS end-user . . .

This company’s main goal was to free up key staff by automating services procurement processes and managing by exception only. The company viewed the software’s event management and associated alerting capabilities as core to achieving this. So when they found a vendor reporting over 200 alerts “out of the box,” that was a big factor in why they chose the solution.

The implementation team diligently gathered the requirements and presented the wide range of alerts to the end-user community. Business line managers were initially very excited at the prospect of being alerted via email when key events took place. The implementation team ended up enabling nearly all of the 200+ alerts.

The result? On Day 1 of acceptance testing, each primary stakeholder on the project who had signed up to do quality assurance received over 100 alerts from the application -- some in their email inboxes, others only in the dashboard. Now, this was clearly a setback but not necessarily a shop stopper. The team regrouped and decided to change the alerting philosophy to really only highlight exceptions in the process. Unfortunately, this is where the project started to come off the rails . . .

The issue? When the team sat down to set up exceptions-only alerts, they found that the configuration was limited to a set of static dropdowns with a limited ability to create any business rules. When the company asked the software vendor about this, it responded “sure, we can certainly help you, but the types of alerts you want will require an enhancement request -- would you like us to give you an estimate for that?” This enhancement request (for what boiled down to 10 specific alerts) that included conditional business rules was quoted out as 120 hours of work. Needless to say, things were not off to a good start. The customer felt like this flexibility should be part of the base solution and that it was being nickel and dimed. Eventually the vendor and customer negotiated a middle ground, but the relationship was scarred and the whole situation could have been avoided.

How? By picking the right software to begin with. Software evaluation teams will sometimes mistakenly focus on the sheer number of alerts available out of the box. While pre-configured alerts can be useful, this is not the best approach. Inevitably, you will need to generate an alert based on a series of events that even the smartest vendor R&D teams did not think of. It’s in that scenario where a process modeling tool / rules engine to configure alerts will come in handy. Look for a solution with a user interface that allows the customer to create IF/ELSE statements from attributes of multiple objects (i.e. Requisition, Contractor, Invoice) and build nested, conditional rules to generate the alert. A non-technical person should be able to create these rules. Some solutions also include a view that shows a process flow once it was created. That can be really helpful for design teams building out more complicated rules. These rules are then used to kick out the alert versus the static parameters I described before.

Here’s an example: In the first phase, this company simply turned on alerts based on these types of events: Requisition, Opened | Requisition, Approved | Requisition, Filled | Candidate, Requires Review | Project Milestone, Acceptance Required | Contractor, On-boarding Checklist Complete | Timesheet, Requires Approval | Timesheet, Approved | Receipt, Overdue | Receipt, Paid | Assignment, Expiring In X Days | Assignment, Extended, Required Approval | Contract, Expiring In X Days | Budget, Within X % Of Maximum, etc.

After the initial information overload, what they really wanted to achieve was something like this: IF the hourly rate is greater than or equal to $200 AND the vendor is NOT EQUAL to Acme Corp. AND the assignment duration is greater than 4 weeks, THEN send an alert message to the “Finance -- Requisition Exceptions Approval” role. Then, if the message is not acknowledged and approved in 48 hours, escalate the message to “VP, Finance.”

This is the difference between basic event alerts and rules-based alerts that help you manage by exception.

Key takeaway: When evaluating a VMS (or any application for that matter), don’t be over-enamored with the sheer number of alerts available out of the box. Instead, look for a solution that includes a modeling tool that a non-technical person can use to build conditional rules that generate alerts. This will give you not only the flexibility required to achieve actual automation you can trust, but you can make changes over time without having to customize the software.

Patrick Connaughton | Senior Analyst - Sourcing and Vendor Management Forrester Research Phone: +1 617-613-6486 | Email: | 400 Technology Park | Cambridge, MA 02139 |


Here are a few specific questions to ask during your evaluation

Can you setup conditional logic to generate alerts? What does the alert setup page look like? Is it just a UI with a list of alerts, drop-downs and text boxes to set the variables? This works OK if you have 10 alerts but what about when you have 200? How do you know how one alert might impact another? How do you build out more complicated if-else type conditional statements? This is where a business process workflow tool comes in. The best software will enable alert configuration through a business process modeling tool that allows even non-technical people to create an if-else statement with multiple conditions across multiple entities.

How are the alerts distributed? Can alerts be displayed not only in a dashboard view but also emailed? Are RSS feeds supported? Is there a standard API to pull these alerts and potentially use in other systems?

Is it easy for end-users to selectively decide which alerts to receive? Without flexible configuration, end-users can quickly become inundated with messages and the software becomes a burden versus an automation tool.

How are alerts prioritized? Alerts should have a priority field that shows up in the subject line of the message itself. In configuration you should be able to build rules taking priority into account.

Is alert distribution set up based on individual email addresses or security roles? You want alert distributions to be based on the roles associated with the software’s security and permissions setup. Each role is associated with a single or group of users and therefore they inherit access to the recommended alerts. This setup makes it much easier as people come and go in an organization, change responsibilities, etc.

Can all parties receive the alerts? In the case of the VMS, you also want to make sure alerts can be set up not only for the hiring party but also the suppliers, MSP(s), contractors, etc. Different languages, local times and unit of measure conversions should also be supported.

How does the alert recipient take action? Make sure the end-user can take action by clicking on a link in the email or the dashboard itself. It is really important to streamline this step to a single click event to ensure adoption. If the alert is merely informational (which I don’t recommend by the way -- remember, manage by exception to avoid information overload!), make sure that’s clear in the subject line of the email or list.

Can you set up business rules for alerts that are visible at each step when using the application itself? Alerting is one thing but you also want to be able to set up the business rules once and apply them to the transactional flow. For example, if you have set a budget threshold you’ll want to know that before you submit a new requisition rather than receiving an alert after the fact. Business rules you use for validation of steps along the way should be reusable when setting up alerts.