What assumptions define a Poisson process for support calls arriving through the day?

## What kind of object this is A **counting process** `N(t)` records how many events have happened by time `t`: it starts at `N(0) = 0`, only ever steps up, and jumps by 1 at each arrival. The Poisson process is the simplest interesting counting process, and it is the default model for 'events landing on a timeline at random with no memory'. ## The defining assumptions 1. **`N(0) = 0`.** Counting starts at zero. 2. **Independent increments.** For disjoint intervals, the counts are independent random variables. Knowing that 9am to 10am was busy tells you nothing about 2pm to 3pm. 3. **Stationary increments.** The distribution of the number of arrivals in an interval depends only on the interval's *length*, not its position. This is the constant-rate assumption, and it is the one that makes the process **homogeneous**. 4. **Orderliness.** Arrivals happen one at a time; the probability of two or more in a vanishingly short interval is negligible compared with the probability of one. That is the whole model, and it has exactly one parameter: the rate `lambda`, in calls per unit time. ## What follows These assumptions pin down the process completely. Two consequences carry most of the practical weight: - **Counts.** The number of arrivals in any window of length `t` follows a Poisson law with mean `lambda * t`. Doubling the window doubles the expected count. - **Gaps.** The times between consecutive arrivals — and the wait from any fixed moment to the next arrival — are independent exponential variables with mean `1 / lambda`. At 12 calls per hour, the average gap is 5 minutes. Those two descriptions are equivalent: you can define the process by its counts or by its gaps and arrive at the same object. ## The Markov connection The exponential holding time is memoryless: given that no call has arrived in the last 20 minutes, the distribution of the remaining wait is the same as it was at the start. That is precisely the continuous-time version of the Markov property. The future of the process depends only on the current count and the current time, never on the pattern of arrivals that produced it. This is why Poisson arrivals slot so naturally into queueing and state-transition models — the jump structure is Markov, so you can reason about the system state without tracking history. ## Three more properties worth knowing - **Superposition.** Merge two independent Poisson processes with rates `lambda_1` and `lambda_2` and you get a Poisson process with rate `lambda_1 + lambda_2`. Each arrival in the merged stream came from the first source with probability `lambda_1 / (lambda_1 + lambda_2)`. This is why pooled queues are tractable. - **Thinning.** Classify each arrival independently with probability `p` — say, calls that need escalation — and the escalated arrivals form a Poisson process with rate `p * lambda`, independent of the non-escalated stream. - **Conditional uniformity.** Given that exactly `n` arrivals happened in `[0, t]`, their arrival times are distributed like `n` independent uniform draws on that interval, sorted. This is the precise sense in which Poisson arrivals are 'completely random in time'. ## Where support-call data breaks the assumptions Stationarity is the first casualty. Volume follows a daily shape — quiet overnight, a morning ramp, an afternoon peak — so a single `lambda` fitted across the day underestimates the peak and overestimates the trough, and any staffing number derived from it is wrong in both directions. The standard repair is a **non-homogeneous** Poisson process with a time-varying rate `lambda(t)`: the count over an interval is Poisson with mean equal to the integral of the rate across it, and independence across disjoint windows is retained. In practice this often means fitting a separate rate per hour or per half hour. Independence is the second casualty. One outage generates a burst of calls about the same incident: arrivals cluster, and the observed variance of hourly counts runs well above what the Poisson model predicts. That over-dispersion is the diagnostic. Repairs range from modelling the incident arrivals as the underlying process, with each incident spawning a batch, to letting the rate itself be random. Orderliness fails when a system re-dials in batches or a queued callback releases several calls at the same second; the model then needs a batch-arrival variant. ## How to check Plot the count per hour across many days and look at the shape — a flat rate should look flat. Compare the spread of hourly counts against what a constant-rate model implies; visible clustering points at dependence. And plot the empirical gaps between calls: a heavy excess of very short gaps is the signature of bursty, non-Poisson traffic.