ServiceNow Platform Performance Requirements Workshop Questions

A performance requirements workshop has to produce recorded decisions on response-time targets, peak concurrent load, database query expectations, reporting and batch windows, integration and API latency, caching, and how performance will be monitored and tuned after go-live. The questions below are grouped by those decisions, followed by how to run the session so the answers are usable and which questions are often skipped and should not be.

Response Time Targets and User Experience Thresholds

The first set of questions focuses on acceptable response times for different operations. How fast should a page load? How long should a query take to return results? What is the tolerance for slowness during peak usage? Different operations have different acceptable times. Loading an incident list might need to complete within a target you set. Running a report overnight might take minutes.

Research suggests that users tolerate: one second for typical operations, three seconds for complex operations, ten seconds for background or batch operations. Anything slower causes user frustration. Responses longer than ten seconds often get clicked multiple times by impatient users, creating duplicate requests and more load.

Another response time question is consistency. Is it acceptable for operations to be sometimes fast and sometimes slow? Most users prefer predictably moderate performance to highly variable performance. Setting targets for 95th percentile response time (most or nearly all of operations complete within this time) helps manage expectations.

Network latency must be considered. For users connecting over the internet (VPN, remote work), network latency adds to server response time. An operation that takes one second on the server might take three seconds to the user if network latency adds two seconds.

Concurrent User Capacity and Peak Load Planning

The next set of questions addresses how many users the platform must support simultaneously. Will the platform be used by 100 people across eight hours, or 5,000 people in a one-hour peak window? Peak load determines infrastructure requirements. If all 5,000 users generate a report at the same time, the database will be overwhelmed.

A common approach is to estimate concurrent users during peak hours. If your organization has 2,000 ServiceNow users but peak usage is between 9 and 11 AM, and only 500 users are active simultaneously, design for 500 concurrent users. This is much cheaper than designing for 2,000.

Another capacity question is growth. Will user count double in the next two years? Does infrastructure need to be over-provisioned to handle growth, or will you upgrade when needed? Over-provisioning wastes money; under-provisioning creates performance crises.

Load testing should confirm that the platform handles expected peak load. Create a test that simulates peak-hour usage with realistic queries and operations. Run the test and measure response times. If response times exceed targets, identify the bottleneck (database queries, CPU, memory, network) and optimise.

Database Query Performance and Optimization

Database queries are often the bottleneck. Questions about query performance focus on what queries must be fast, how queries will be monitored, and who optimises slow queries. Common slow-query culprits are missing indexes, unoptimised joins, full-table scans, and queries in loops.

Index strategy determines query performance. Properly indexed columns return results quickly. Missing indexes force full-table scans that examine every row. A balance is needed: too many indexes slow down data writes. Too few indexes slow down queries. Database analysis can identify which columns should be indexed based on query patterns.

Query monitoring should identify slow queries. A dashboard showing query execution time helps database administrators spot problems. Common queries that run slowly under load (fine with one user, timeout with one thousand) indicate that optimisation is needed.

Complex queries, scripts that query inside loops and heavy business rules should be reviewed by someone with database knowledge, not left to developers who may not understand database optimisation., not left to developers who may not understand database optimisation. Similarly, batch jobs that run nightly should be optimised to complete before morning users start working.

Reporting and Batch Processing Load

Reports can significantly impact platform performance if not designed carefully. Questions about reporting focus on what reports run, when they run, and how heavily they load the database. A company-wide daily report that joins five tables and processes millions of rows consumes resources that could be serving interactive users.

A practical approach is: separate reporting from transactional database. Use a data warehouse or reporting database that receives data feeds from the transactional system. Reports run against the warehouse, not the live system. This separation prevents large reports from impacting user experience.

If separate reporting infrastructure is not available, schedule reports during low-usage windows (evenings, weekends). Limit report frequency (reports run daily, not hourly). Restrict large reports to users who really need them rather than making reports widely available.

Batch processes should run similarly: during low-usage windows, or asynchronously so they do not block interactive operations. A data import that processes thousands of records should complete in the background, not hold up incident handlers.

Integration and API Performance

Integrations can impact platform performance if they are not designed carefully. Questions about integration performance focus on how data flows between systems, how much data moves, and what happens when integrations are slow.

Real-time integrations (blocking synchronously until data is confirmed in the other system) are slower than asynchronous integrations (queue the data and sync in the background). Real-time integrations are necessary for critical data but should not be over-used. Asynchronous integration for non-critical data allows the platform to respond to users quickly.

Integration batch size matters. Syncing one record at a time creates overhead. Batching records (sync fifty records in one request) is more efficient. However, batching introduces delay (wait until fifty records accumulate before syncing).

API rate limiting should be considered. If you have many integrations, all calling your APIs, can the platform handle the load? Rate limiting (restricting API calls per minute) protects the platform but may slow integrations. Careful design of integration frequency and batch sizes minimises rate-limiting issues.

Caching and Content Delivery

Caching reduces database load by storing frequently accessed data in memory. Questions about caching focus on what data is cached, how long caches are valid, and what happens when cached data becomes stale.

ServiceNow includes built-in caching for configuration data and certain queries. A customer cannot add a cache layer of its own to a hosted instance, so the questions are about what the platform already caches, which client settings affect it, and how scripts avoid repeating the same lookups inside a loop. Cache invalidation (knowing when to discard stale cached data) is a common challenge.

Static content such as images, stylesheets and scripts is served by ServiceNow’s own infrastructure, and a customer cannot place a content delivery network in front of a hosted instance. For global users the useful questions are about network paths, browser caching settings and the size of custom portal assets., reducing latency. For global users, CDNs can significantly improve performance.

Monitoring, Alerting, and Continuous Optimization

The final set of questions focuses on how performance will be monitored and how optimisation will be prioritised. Will you monitor response times continuously? Will you have alerts if response times degrade? Will you track trends to identify degradation before it becomes critical?

Performance monitoring should track metrics: average response time, 95th percentile response time, error rate, concurrent users. These metrics should be visible to operations teams and used to drive optimisation decisions.

Performance degrades over time as data volumes grow and customisation accumulates. Regular optimisation efforts (quarterly or semi-annual) prevent performance crises. Performance reviews identify slow operations and prioritise optimisation work.

The warning sign is performance problems discovered by users, not by monitoring. If users complain that the system is slow before operations teams notice, monitoring is insufficient. Implement monitoring before problems appear.

Turning each question into a recorded decision

A workshop on performance requirements produces value only if its answers can be written down as decisions that someone will later check. A question such as how quickly the approval list must open is not finished when the room agrees on a figure. It is finished when the figure, the screen it applies to, the people who agreed it and the date they agreed it are all recorded in the requirements log. The table below shows the difference between an answer that can be built against and one that cannot.

Running the session so the answers are usable

Many workshops drift toward general agreement because the people in the room are not the ones who will live with the consequences. Keep the session on the screens and processes that matter, and assign each question an owner before discussion starts.

1. Start with the three screens or processes that users complain about most, and agree what they must do before discussing anything else.
2. For each requirement, ask who will check it and how. A requirement with no check is a wish.
3. Write the answer in the wording the record will use, and read it back to the room before moving on.
4. Mark any answer that depends on an external team or a future decision as open, naming the person who will close it.
5. Send the recorded answers to the attendees within a day, so corrections are made while the discussion is fresh.

Questions that are often skipped and should not be

Teams often leave out asking what happens when a requirement is missed. Ask it. The answer determines whether a slow period triggers a fix, a conversation with the business or nothing at all. Ask also which users the requirement protects, because a target agreed for the whole organization can hide a single office or role that is struggling. Finally, ask what the team will stop doing to meet the requirement, since performance budgets are often spent by displacing other work.

Access questions tend to surface in the same session too, and the answers are handled by the security and access design guide while the requirements workshop decisions article widens the lens on how these sessions produce decisions rather than discussion.

How many requirements should one session cover?

Few enough that every one gets an owner and a check. A session that covers too many requirements usually records vague answers.

What if the business cannot give a number?

Ask for the decision the number would support, such as whether a slow screen justifies a change this quarter. The requirement can be written as a threshold to be set after a baseline exists, with a date.

Should technical staff attend the business sessions?

Yes, but they should answer only for what they can measure. Their role is to say whether a requirement can be checked, not to decide what the business needs.