Two things to respond to:

Workflow I feel that the build vs buy decision (size and urgency plays a part as well) is really told in the process modelling. This is also something that is tragically missing from most vendors software documentation. The most difficult thing to do is not write software but change people habits. The cost of that should be added to the formula (intelligently - thumb suck guesses don't count) to make the BvsB decision. Every piece of business software has interaction and process assumptions built into it. If you can find software that matches your process (or desired processes) the buy decision is easy. I am currently assisting a company that is doing a large scale ERP upgrade. I was invited in after the crash was obvious to avert it (accomplished that) and one senior employ quit because she "couldn't go through this again." The chief pain point is none of this process work was done. The lesson here is that even when upgrading a current system B vs B uis a reasonable question. I had a sign on my office wall for a number of years that said "If you can't write it down, I can't build it." That includes processes. To paraphrase Joe Walsh "You can't know where you going if your don't know where you are"

Buying for Bells and Whistles - I must confess, I am not a pretty UI kind of guy. From years of working with marketing people, I find if someone is trying to impress me with features my instinctive response is to wonder what they are trying to cover up. Time always limits the final product. So if the vendor has invested in this what did they choose to leave behind. There are those vendors who, like street hucksters, like to do feature slight-of-hand. Thankfully I think they are few. However, a list of what it doesn't do is as important as a list of what it does when considering features.