Self-Service Software Portals – What Features are Important?

By Brett Husselbaugh

Many of the businesses that we speak with regarding their ITAM/SAM requirements have, or are in the process, of implementing some form of self-service request system, with one of the items that can be requested being software. The driver is typically in response to user demand and/or the desire to reduce ticket volume and the associated resources required to address that volume. However, what is often not considered are the requirements of the Software Asset Management (SAM) practice. This is generally due to the SAM practice not realizing there are SAM-specific requirements that should be driven into the self-service request system for software.

So let’s take a look at those important SAM specific design criteria for a self-service software portal, in order of importance.

Design Criteria 1: Speed

The software request portal must be as fast as or faster than any other conceivable way of acquiring software, as measured from the time the request is made until the time the software is installed and ready to use.

One of the largest threats to establishing and holding software license compliance is what is known as “back channel acquisition,” defined as finding a way to acquire and install software through any means other than the one(s) officially prescribed by the organization. And, yes, this also happens in organizations that consider themselves to be completely “locked down,” that is, where the general user does not have privileges to install software on their workstation or laptop. What happens over time is that an appreciable quantity of deployed software will be found and counted, but it will have no corresponding purchasing information, and therefore no way of proving a licensed position.

In order to combat “back channel acquisition,” the prescribed means of acquiring software must, among other things, be the fastest and easiest possible. People will always seek and find the path of least resistance. It is therefore important when designing the self-service channel for acquiring software that it is as fast as, or faster, than any other way of acquiring software – and that includes downloading and installing directly from the internet. It does no good if the web-based front-end is fast, but continues to feed a clumsy and/or otherwise time consuming process on the back end. Users consider the entire cycle time – from the time they request the software until it is installed and ready for their use – not just the time it takes to fill out the initial request. In many cases, the back-end process needs to be changed to meet this requirement for software.

In addition to addressing speed for reasons of enticing people to use the prescribed ordering channel, speed is also important to encourage department/project managers to give up software licenses they are not using, so that they can be harvested and used elsewhere in the organization. One of the common complaints ESI hears with new clients is how long it takes to go through the software request process, and that the cycle time is a deterrent to giving up unused software as managers do not want to have to endure the request cycle again – so they decide to continue to hold on to unused software.

Design Criteria 2: Accuracy

The software request portal must be accurate, ensuring that the title that was ordered is the title that is installed, correct both in edition and version. Again, this is as measured across the entire request/install cycle. Accurate ordering is of no value if some title, other than what was requested, is installed.

How often does this happen? As an example, in practically every client ESI has worked with there is a common theme – “Standard” is requested (or assumed) and “Pro” was installed. This common theme consistently results in an out-of-compliance condition. In another example, one client had created an internal “push” console, integrated with Microsoft’s SCCM product, to allow the help desk to schedule requested software to be automatically pushed and installed on the requestor’s machine. However, the wrong package was pushed on occasion because the process relied on a human being selecting the proper software package from a list of similar-looking titles, resulting in an ongoing and measurable error rate in the process. Oftentimes, the user won’t complain, especially in the case where a different edition and/or version of the intended software was installed, so the installation will not be corrected and an out-of-compliance condition ensues and worsens over time.

Design Criteria 3: Demand Control

The software request portal must include a built-in throttle for demand, to deter “runs” on available licenses and to maximize the probability that the software being requested will actually be put to use.

If the SAM practice is going to create value by harvesting and re-using software, the last thing needed is to make it too easy to request and consume licenses that were freed up and made available to be used again. If not careful, creating a speedy process without a proper demand throttle can backfire, resulting in simply moving licenses from one place where they were not being used, to another place where they will also end up not being used.

Design Criteria 4: Detection

The software request portal must have a reliable means to detect when the prescribed channel for requesting software has been circumvented. There must be a reliable means to audit compliance with the prescribed channel for requesting software. Even if all design criteria are met or exceeded, people will still circumvent the system. Hopefully, there will be fewer who do, but there will still be some. Circumvention must be easily detected so that proper behavior drivers can be used to continue to encourage desired behavior and/or discourage undesired behavior.


In 2006, when we were laying the design groundwork for the first client that agreed to use our approach to managing software and the organizational behaviors that surround it, it quickly became clear to us that a software request portal was not just a nice-to-have feature – it was an essential element of the solution and necessary if we were to be successful. We needed a way to make sure people requested and deployed software in a way that allowed us to capture and record the associated purchase of licenses – so we realized we had to make our process fast and easy.

We also needed to stop the practice of installing “Pro” when “Standard” was requested and/or would have sufficed – so we needed accuracy.

Another point we wrestled with was the concept of harvesting and creating available pools of licenses. The question kept coming back to “what’s to stop people from requesting harvested licenses once they find out they’re available?” We knew that would result in our solution just moving licenses around from one place where they weren’t being used to another – and the value we had created through harvesting and re-using licenses would be at great risk. We needed a demand throttle and we finally arrived at the simple solution of charging for the software request, whether a license existed or not.

The years we had spent to that point implementing asset management for clients had taught us one thing if nothing else – there will always be those who will ignore the process and figure out ways to circumvent it. So we knew we needed not only an easy way to detect when that was happening, but also a way to discourage it. Our experience to that point was also overwhelming in that financial motivators were the only practical behavior drivers that worked. We had tried many other ways without sustained success, so we decided on simply charging normal price for rogue installations. What was interesting in our experience was that the concept of charging against internal budgets and/or issuing credits (also part of our behavior drivers) was originally expected to be shot down by the Finance organization. What we found was quite the opposite. Once we explained how it worked, those Finance organizations we have worked with actually embrace it, much to the continued surprise of their IT counterparts.

At this time of writing, some seven years later, we feel the results have been conclusive. The Software Request Portal, along with financial behavior drivers has been an overwhelming success. It has exceeded expectations and been one of the brighter, and most visible, pieces of the SAM solution, resulting in praise for the SAM professionals within their organizations.

About the Author

Brett Husselbaugh

Brett Husselbaugh is the President of ETelligent Solutions, Inc.