Using several CRM and ERP system I've noticed that many of them suffer from poor performance. Specially SaaS CRM system can have response time of several seconds (1-4s). But I've also seen this problem in native systems.

I was quite surprised about this because a system that is frequently used, then even this few seconds will add up to days yearly, or even (working) weeks.

Even more surprisingly is that people working with those systems are actually quite happy with them. They do not consider performance to be an issue and think that the system is fine.

Why is this accepted?

Why do we value distribution, user interface, and rapid design over fast software? Software is used by many people and time adds up, it should be economical cheaper to write faster software.

Reasons I've found is:

  • It's not a requirement and people do not choose their own software. If for example our favorite online newspaper is slow, we can always change newspaper. Then speed is important for that website. However a user of a ERP or CRM system can rarely change system that easy.

  • It's not important. That time you're waiting for the system to respond is used to do something else (for example, think and process information).

  • The time is considered insignificant since we already have toilett breaks, water cooler talks, etc. that are much worse time thieves.

I notice that this question is open for speculation, but I would be very happy to see any research on this area (that is, fast user interface) as I've found very little.

I've however found research about user behaviour on search engines depending on response times. That's not my question.

2 Answers 2


Performance is a complex topic. I think, given the choice, people will usually prefer faster response times over slower times. There are many contributing factors to response times, especially with the move to cloud-based systems/services (network latency being an obvious factor to consider).

The dilemma with enterprise software, such as ERP systems, is that they are usually extremely expensive to implement and maintain. These systems are sometimes integrated with other third-party software from different vendors, or part of a larger landscape of inter-connected systems, with teams of people employed around the clock to make sure that service level agreements are not violated by a system that suddenly goes offline without prior agreement/notice. In that sense, businesses take performance very seriously.

Picking an ERP system is one of the biggest software investments your company will make. Your deciding factor is not going to be the difference between 1s and 3s response times. It will be price, features, stability, support, maintenance, and if it is the best fit for your industry/business. Depending on the system, you may even have to change your internal business processes to be more in line with the way the software "expects" things to happen.

Large ERP implementations can take more than a year, with many consultants on-site to do configuration and training. It costs a lot of money, but in the end, it is the backbone of your day-to-day operations, finance and human resource functions. Is it worth the occasional excess 2s in response time? From a business perspective, yes. Would they prefer a faster response time? Sure. Will they pay for a faster response time for user-facing actions? It depends, but probably not if it means switching ERP systems. And they won't switch for a 2s improvement in UI response time. At best, they may look into upgrading the server infrastructure (if they have that option).

Performance (or web-application performance specifically) can actually be split between:

  • the time before you receive a response from the server after making a request (sending the request over the network, performing "back-end" processing (checking security permissions, fetching data from different systems/databases, consolidating the results etc), sending it back to the browser)
  • the time spent rendering the response in the browser (parsing the DOM, fetching resources such as images and Javascript libraries, rendering the page, executing Javascript routines, and maybe even pulling in material from third-party content providers or social media sites (the sharing buttons, or tracking beacons etc).

I have worked on large scale deployments of enterprise systems, and "acceptable performance" really depended on the environment. For the SAP Basis consultant it meant a response time of 2.5 seconds under normal conditions, even though this could spike up to a minute or more under heavy load. Response time here is basically asking the system for a status update, and receiving a response within that time (not to be confused with pinging a system). For the IT manager, performance was defined by the service level agreement, and could mean that 90% of the requests made within an hour period should each respond within 2 seconds (this means back-end processing, not browser rendering time). This was measured within the same data-center, and did not factor in latency due to geographical location.

My experience is limited to systems used internally by businesses, which seems to be what you were asking about. There are companies that take front-end performance (browser-side) very seriously, but they are mainly targeting the public (individuals), where perceived performance is a much larger deciding factor when choosing to use the service or not.

There is existing research on how long users are willing to wait for a response from the system, before thinking that something went wrong. I believe this was in the 10 second range, but I will have to look up the source. The research was done in the 80's, with users of text terminals if I remember correctly, but I will have to double-check. You can also refer to Jacob Nielsen's response time limits for a general guideline on application response times.


Why is this accepted?

A few reasons why this happens:

  1. The people that use, install, and support the software are rarely the people that buy the software.
  2. A lot of this software is vendor provided. It's "easier" to blame a vendor for bad software than to build your own software and have to take responsibility for it.
  3. Habit/defacto 'standards'
  4. Good sales teams can sell anything.

No one uses SharePoint or WebSphere or Clearcase or Peoplesoft or Lotus Notes because of stellar UX. They use them because their company paid for them.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.