00 — What this tool does
The Building Traffic Flow Analyser models how people move through a building's primary circulation point — arrival, queuing, standing, and departure — and checks that flow against the systems that actually govern it: reception/turnstile throughput, floor space, fire-code egress, and vertical transportation. A lobby is never sized in isolation; it's sized to whichever of these is weakest.
Two ways to use it: Tab 01 is the full parametric model (queueing theory, calculated PHF, real elevator traffic formulas). Tab 02 is a fast, deliberately conservative thumb-rule check. Both now generate a short Insights panel — plain-language analysis synthesized live from whatever you've entered, not a canned summary.
Running more than one shift? Tab 01's Shift Mix lets you add up to four concurrent shifts, each with its own population share — the Daily Traffic Profile chart combines them by superposition and automatically flags where one shift's departure collides with another's arrival.
Default scenario loaded: Industry = FSP / BFSI Global Capability Centre. Shift = General / Day, India (09:00–18:00). Both are changeable in Tab 01.
01 — Defining "Peak"
Peak is never a single number. Designing to the worst 5 minutes ever observed wastes area; designing to the daily average undersizes it. The standard approach uses two nested measurements:
PHF — the Peak Hour Factor — captures burstiness. PHF = Hourly Volume ÷ (4 × busiest 15-min volume). A PHF near 1.0 means arrivals spread evenly through the hour; a low PHF (0.6–0.7) means arrivals are bursty, which is the normal pattern at 08:45–09:00. Low PHF is what actually breaks a lobby — the instantaneous crowd is worse than the hourly average suggests.
Illustrative 60-minute arrival profile — same total volume, different PHF. A lower PHF concentrates the same people into a sharper spike.
Tab 01 plots your own building's arrival curve overlaid with its departure curve on a real clock, and flags any window where the two overlap — see "Daily Traffic Profile" there.
02 — Pedestrian Level of Service (Fruin)
Once you know how many people could be in the lobby at once, check that headcount against space-per-person standards. This is the standard reference used in building and transit-terminal planning for standing/queuing areas:
Figures are commonly-cited Fruin standing-space boundaries; treat as reference, not statute — confirm against your own project's pedestrian LOS standard where one is specified. Corporate reception lobbies are typically designed to LOS B or C at peak; transit hubs tolerate LOS D.
03 — Queueing: Little's Law & Erlang C
A reception desk or turnstile bank is a service system, not just floor space — this is the part most lobby sizing exercises skip, and it's usually where congestion actually comes from.
λ = arrival rate (people/min) · c = number of lanes/servers · μ = service rate per lane (people/min) · W = average time a person spends in the system · L = average number of people in the system at any instant.
If arrivals (λ) sustain above total capacity (c × μ), the queue grows without bound — that is the actual bottleneck, not floor area. This tool solves the exact M/M/c (Erlang C) queue for wait time, then adds a "post-clearance linger" term (people waiting for an elevator or escort) to get the real instantaneous lobby population, which is what the LOS check should be run against — not the raw arrival rate.
04 — Occupant Load vs. Egress Width
Two different numbers, often confused. Occupant Load Factor (OLF) is a code-assigned area-per-person figure (e.g. IBC Table 1004.5) used to compute the legal maximum headcount for the space — it is a ceiling, not a design target, and is normally denser (fewer sf/person) than your comfort/LOS target. Occupant load itself is floored to a whole number of people (Area ÷ OLF, rounded down) — you cannot legally count a fractional person. Egress width is sized off that occupant load, not off your expected traffic:
Width-per-person factors and OLF values vary by code edition, sprinkler status, and jurisdiction. Tab 01's Occupant Load Classification selector (next to LOS Target) offers two common reference values as a one-click quick-set for the Code Occupant Load Factor field: Assembly — Standing/Waiting (5 sf/person, a denser, more conservative classification) and Business/Office Area (15.07 sf/person, ≈1.4 sqm — a less dense classification some jurisdictions apply to a reception lobby treated as ordinary business floor area). Which classification legally applies to your specific space is a jurisdiction question — verify locally; the tool does not decide this for you.
Optional: metric (mm/person) egress check
Alongside the imperial-style Egress Width Factor check above, Tab 01 offers an optional NBC-style metric check using per-component width factors:
Default factors: 10mm/person for staircases, 6.5mm/person for corridors and clear door width. Every required width is rounded up to the nearest 500mm module (matching standard door/corridor modular sizing) and floored at a 2m (2000mm) minimum at reception level. Available staircase width, corridor/door width, and fire safety door width are all optional inputs — enter them to get a pass/fail margin, or leave them blank to see the required widths only. This check is additive: enabling it does not disable or replace the imperial check.
05 — Vertical Transportation (Lifts)
In practice, lifts — not the lobby floor — are the most common real bottleneck in a multi-storey building. Elevatoring is sized on the standard 5-minute handling capacity method:
RTT = round-trip time of one car (sec). HC5% is the share of the served population that can be moved in any 5-minute window; typical office targets sit around 11–17%. Interval is the average gap between car arrivals; ≤30s reads as excellent, 30–40s adequate, beyond that, queuing at the lift lobby becomes visible. Note the two metrics can disagree — a short interval with too few, too-small cars still yields a poor HC5% once population is large, which is exactly the tension a big single lift bank runs into.
06 — Lift Banks, RTT Derivation & the Real-Time Check
A building rarely has just one undifferentiated pool of lifts. Tab 01 models any number of independent lift banks — a main passenger bank, a basement-to-reception jump lift, any other independent group — each with its own lift count, car size, RTT, and population served. Every bank is checked on its own; the governing constraint is whichever bank's weakest check is worst overall.
Each bank's Population Served can be set three ways: a percentage of total headcount, Car + two-wheeler arrivals only (drawing directly from the Basement Parking group's spaces and occupancy factors — the correct way to model a jump lift / basement shuttle), or a custom fixed number. The + Quick Add: Basement Shuttle button pre-configures a new bank in car+bike mode so you only need to fill in its lift count, capacity, and RTT.
Deriving RTT instead of assuming it
RTT depends on how many floors a bank serves, not just a generic "building height." Each bank can either take a typed RTT, or calculate one from first principles:
H = expected highest reversal floor (simplified here as ≈80% of floors served) · tv = seconds per floor = floor height ÷ car speed · S = expected probable stops = N×(1−(1−1/N)^P) · ts = door time per stop (input) · P = practical passengers per trip = car capacity × 0.8 · tp = 1.2 sec/passenger boarding/alighting (fixed). This is a planning-stage approximation — a full elevator traffic study refines H and S using manufacturer dispatch data.
Two different lift checks, on purpose
Each bank reports two independent margins, and they can disagree:
- HC5% (industry-benchmark method) — what fraction of the bank's total served population could be moved in the worst 5 minutes. This is the standard, published sizing method and the one most elevator consultants quote first.
- Real-time queue (arrival-rate method) — bank capacity in people/min, compared directly against λ, the rate people are actually arriving at that lift lobby right now (fed from the same peak-hour model that drives the reception queue). This answers a different, complementary question: is a queue visibly forming at this exact moment, independent of how the whole building behaves on average.
07 — Governing Constraint
Every independent check — reception/turnstile throughput, LOS density, code occupant load, egress width, and each lift bank's HC5% and real-time queue — is expressed as a margin: (capacity − demand) ÷ capacity, as a percentage — so they can all be compared on one scale, the way a structural engineer compares factors of safety across different failure modes.
08 — Tab 01 vs. Tab 02: why they disagree
Tab 01 models concurrent occupancy properly — most of the people who arrive in a 15-minute window pass through in seconds and are never all in the lobby at once. Tab 02 (thumb rule) skips that distinction and multiplies the raw 15-minute arrival volume directly by a target density, which is a deliberately conservative, back-of-envelope simplification. Expect Tab 02 to call for noticeably more area and more lifts than Tab 01 — that gap is the value queuing theory adds, not an error in either tab.
Tab 02's elevator check is no longer a flat assumed ratio either. It now asks directly for Number of Floors Served, which selects an RTT band (≤6 floors → 75s, 7–15 → 110s, 16–30 → 155s, 30+ → 200s), and combines that with a target HC5% to derive a people-per-lift ratio — the same underlying logic as Tab 01's HC5% formula, just collapsed into round numbers for speed. It also asks for Passenger Elevators, Fire Lifts (counted together, since fire lifts run as passenger cars day-to-day), Jump Lifts — lifts that carry basement parking arrivals up to the reception floor, shown separately and excluded from the main ratio since they serve a different population and a much shorter trip — and Number of Lift Banks — because how many independent banks share that lift count changes what "enough lifts" looks like floor-plate by floor-plate, even at the thumb-rule level.
Tab 02 also has its own Daily Traffic Profile chart — a simplified single-shift arrival-vs-departure overlay built from its own % Peak Hour, % Busiest 15-min, and Arrival Peak Time inputs, with the same common-peak overlap detection as Tab 01. It is illustrative, not a substitute for Tab 01's PHF-calculated, multi-shift-aware version.
09 — Reading the Insights panel
Both tabs generate a short Insights block above the detailed tables — a set of plain-language findings written the way a traffic/facilities analyst would summarize a report: a headline verdict, a benchmark comparison for vertical transport, a read on queueing behavior, a density/LOS characterization, the arrival-vs-departure pattern, and a "where to focus next" recommendation.
Severity color-coding in the Insights panel follows the same red/amber/green convention as the Margin of Safety chart: red = failing at the modeled peak, amber = tight, green = clear headroom.
10 — Blank Inputs, Guidelines & Presets
Every numeric field in both tabs starts empty. What you see in grey inside an empty field — or in a small note beneath it — is a guideline value: a reasonable industry starting point, not a filled-in answer. Calculations always run using your own entries where you've provided them, and fall back to the guideline wherever a field is still blank, so the tool never shows a broken or empty results panel while you're still filling it in.
Two buttons sit at the bottom of each input panel: Clear All Fields resets everything back to blank/guideline, and Load Example Scenario fills every field with the worked example used throughout this documentation (FSP/BFSI GCC, General/Day India, 9,000 headcount) so you can explore a fully-populated, working scenario immediately. Dropdowns that drive several fields at once — Industry, Shift, Occupant Load Classification — also start unselected; picking one fills in the fields it controls, and you can still override any of them by hand afterward. Adding a second shift or a new lift bank never auto-picks a preset or a percentage split on your behalf — those stay blank until you choose them explicitly.
11 — Attendance Scenarios: Day 0 / Day 1 / Day 2
Designed headcount and who actually shows up on a given day are two different numbers, and a lobby sized only for one of them is either badly oversized most days or fails on the days that matter. Tab 01's Attendance Scenario selector runs the entire model against three named cases:
- Day 0 — Design / Max Capacity (100%, fixed): the full designed headcount, present all at once. The hard ceiling every system must clear — this is what code compliance is checked against.
- Day 1 — Average Attendance: a typical working day, reflecting hybrid/WFH patterns and normal day-to-day absence.
- Day 2 — Peak Attendance: a high-attendance day — all-hands, month-end, a festival return-to-office spike.
Average and Peak attendance rates are editable peer-industry benchmarks, driven by the selected Industry preset (for example, FSP/BFSI GCC defaults to 75% average / 85% peak) — change the Industry and the guideline rates change with it, or override either rate directly. Design population, car/two-wheeler-derived headcount, and every downstream calculation (reception queue, density, egress, lift banks) scale together by the same attendance rate, so the Daily Traffic Profile chart, the Insights panel, and the exported report all reflect whichever scenario is currently selected.
12 — Exporting a Report
Both tabs have an export toolbar at the top of the results: Project / Site name, Prepared for, Prepared by, and three buttons — Export Full Report (PDF), Export Full Report (.doc), and Export 1-Page Summary (PDF).
The full report is a proper letterhead document: a cover page (title, project, prepared for/by, date), an Executive Summary with large headline stat cards, the Insights panel, the Day 0/1/2 Scenario Comparison, Key Inputs, a full Detailed Analysis section for every one of Day 0, Day 1, and Day 2 — not just whichever scenario is currently selected on screen — each with its own population/λ/margin stats, results table, Daily Traffic Profile chart, and Margin-of-Safety chart, followed by an Assumptions & Data Provenance table (flagging which inputs are your own data versus still-guideline defaults), Methodology Notes, and a Sign-off block with Prepared/Reviewed/Approved-by lines. The 1-Page Summary is a condensed alternative — headline stats, governing constraint, one chart, sign-off — sized to fit on a single page for sending to leadership.
PDF export uses the browser's native print-to-PDF via a dedicated print stylesheet, with the Daily Traffic Profile and Margin-of-Safety charts embedded as real images. Word export builds a Word-compatible HTML document with A4 page setup, downloaded as a .doc file that opens directly in Word, Google Docs, or LibreOffice — it uses the same content and page breaks but stays tables-and-text only (no embedded chart images), since inline SVG support in Word's HTML import is unreliable enough that a clean table beats a chart that might not render.
13 — Saving and Loading a Session
A session bar sits just under the title block, visible on every tab: Save Session, Load Session, and a status line. This is separate from exporting a report — a session file captures every input on both tabs so you can pick up exactly where you left off, hand a scenario to a colleague, or keep a library of past projects.
Save Session downloads a .json file containing every field on Tab 01 and Tab 02, timestamped and versioned. It uses a standard browser download rather than a native "save as" dialog — the File System Access API that offers the latter is unreliable when this file is opened directly from disk (file://), which is how this tool is normally used, so enable "Ask where to save each file" in your browser's download settings if you want to choose a location every time.
Load Session opens a file picker; selecting a previously saved .json file restores both tabs to that exact state, including which Attendance Scenario was selected. Loading is tolerant of older or partial files — any field missing from the file falls back to the same guideline defaults a fresh page load would use, rather than breaking, so a session saved by an earlier version of the tool will still load cleanly.