Guides
Office Wi-Fi Requirements: Separate People, Devices and Concurrent Tasks
Prepare a Wi-Fi demand worksheet with device groups, usage locations and concurrent tasks, using a transparent counting example without guessing equipment capacity.
DETIAN ICT · Tanzania & East Africa
Discuss your ICT project with DETIAN.
DETIAN ICT supports audiovisual, security, network and smart-building projects in Tanzania and East Africa, with design, equipment supply, installation and maintenance services.
Share your site location, required systems and available drawings or equipment list. Start a discussion about the work scope and the information still needed.
Describe the devices and tasks that may overlap
Before asking for an office Wi-Fi proposal, list the devices expected in each area, what people need to do with them and which activities may happen at the same time. Keep employee headcount, devices present, devices expected to connect and devices actively performing a task as different figures. A list of twenty staff does not, by itself, describe the wireless requirement.
For an office, training area or project compound in Tanzania or elsewhere in East Africa, a demand worksheet gives the designer something more specific to review than “good Wi-Fi everywhere.” DETIAN’s network-planning information asks for user and device numbers, locations, building layouts and existing cabling. The worksheet below develops the usage part of that enquiry; it is not a radio design, a bandwidth calculation or a recommended access-point quantity.
Count people and devices in separate columns
Begin with the actual area and the group using it: office staff, a meeting group, visitors or another defined user group. Record the source and date of the information. A current staff list, a proposed seating plan and a forecast of visiting attendees describe different things. Mark estimates as estimates instead of merging them into an apparently measured total.
List the relevant device types and how they are intended to connect. A person may bring a laptop and a phone, but the project may not intend both to use the office wireless service. A shared room device may serve several people. Ask the owner which devices belong in the requirement and keep unresolved decisions visible. Do not turn headcount into a universal devices-per-person allowance.
Keep the number physically present separate from the number expected to connect in the scenario being discussed. Then describe the active tasks. A connected device that is idle and one taking part in an agreed task are different entries for the purpose of explaining use. The technical team must decide how those requirements affect its design; the worksheet does not assign a standard load to either state.
Give each usage scenario a place and a time
Use a room or zone identifier that matches the current floor plan. Describe whether people remain at desks, gather for a meeting or move between named areas. Where movement matters, state the task that needs to continue and ask how the proposed solution would be assessed for it. Do not infer a successful moving-use experience from a drawing of nominal coverage.
Identify the periods that matter to the owner, such as an ordinary morning, an all-staff briefing or a visiting training group. A busy event and a quiet afternoon should not be averaged into a single unlabelled number. Record whether different groups overlap or replace one another, and distinguish a recurring requirement from an occasional event still under discussion.
Keep locations and usage connected. The existing location-schedule guide helps mark the right room or work area on a drawing. This worksheet adds what the devices are expected to do there and when. It does not relocate an agreed connection or assume that equipment in a nearby room can serve the requirement without assessment.
Use a demand row that a designer can question
Useful fields are: scenario ID; site and plan revision; room or zone; user group; device type; number present; number expected to connect; intended tasks; estimated simultaneous active devices; time or event; information source and date; confidence or unknowns; and the person who can confirm the requirement.
Write tasks in the owner’s language, such as opening the approved business application, joining a meeting or accessing agreed training material. Identify relevant application information through the authorised project process. Do not invent a required data rate or declare a performance threshold simply to fill an empty column. Ask the technical reviewer what supporting information is needed.
Keep guest, staff and shared equipment requirements identifiable, then ask the responsible team to define the appropriate access arrangement. Listing those groups is not a configuration instruction or permission to change security settings. The general enquiry should not contain passwords, access tokens, private user lists or confidential application records.
If the task also relies on an internet connection or another system, record that dependency and its owner. A wireless design discussion should not quietly become a promise about an external service. Ask the parties to identify the scope and checks for the complete task, with any unconfirmed dependency left explicit.
Work through a fictional twelve-person office
The following numbers are invented to illustrate counting, not to size equipment or estimate network performance. Suppose an office has twelve staff. Each has one laptop. Nine also bring a phone. The group therefore has twelve plus nine, or twenty-one, devices physically present in this simplified example.
For the scenario under discussion, the owner intends all twelve laptops and six of those phones to connect to the office Wi-Fi. The expected connected count is twelve plus six, or eighteen. The other three phones remain in the physical-presence count but are not included in this scenario’s connection requirement. This distinction must come from the stated assumption, not from a designer guessing how staff will use their phones.
During a defined work period, the owner estimates that eight laptops will use the shared business application, two different laptops will join a meeting, and four of the connected phones will perform a named permitted task. If these are distinct devices and the activities really overlap, the worksheet records eight plus two plus four, or fourteen, simultaneously active devices for that scenario.
The other four connected devices are not assigned an active task in this example. That does not establish zero traffic, a guaranteed spare capacity or a universal concurrency ratio. Nor can the fourteen be multiplied by an invented rate to produce a supported bandwidth specification. The example only demonstrates how the categories relate when the assumptions are stated.
If the two meeting laptops are actually included among the eight application laptops, the active-device count must not count them twice. Keep both task requirements, identify the overlapping devices or group and ask the technical reviewer how simultaneous tasks should be considered. A device count and a task count are not interchangeable.
Record observations without turning them into guarantees
For an existing office, distinguish an authorised observation from a future requirement. Record where and when a task was observed, the device or defined group involved and the limits of the observation. One successful task at a quiet time does not demonstrate the proposed busy-period scenario. An informal complaint is useful context but is not a measured coverage or capacity result.
Ask whether a site assessment is needed to resolve unknown layout, materials, existing equipment or interference conditions. The appropriate technical team should define any survey, measurements and design method. Office staff should not move access points, change channels or interrupt an operating network merely to complete this enquiry sheet.
If the owner expects future growth, give that future scenario its own date assumption and status. Do not silently add it to the present headcount or treat an unapproved expansion as an immediate purchase requirement. Ask how a proposal addresses the present requirement and what would need another review if the scenario changes.
Agree what the proposal and later checks should answer
Send the worksheet with the named layout revision and ask the supplier to identify the scenarios covered, assumptions made, information still required and any dependencies outside its scope. A proposal listing equipment quantities should still explain which usage requirement those quantities are intended to address. The worksheet itself cannot validate the design.
Before acceptance, ask the owner and technical team to agree suitable task checks, locations, representative devices, timing conditions and evidence to retain. Use authorised sample material. Keep an unperformed busy-period or moving-use check visible as untested; successful association with the wireless network is a narrower observation than completion of the agreed business task.
If the work involves changing a live installation, the interruption and go/no-go arrangements need their own review. If it is a new installation, agree the handover evidence and unresolved-item list. Neither the demand worksheet nor a scheduled visit grants permission to interrupt an operating system.
Bring DETIAN the location, use scenarios and open questions
For a project discussion, prepare the country and town, site type, relevant floor plan, current or proposed user groups, device categories, usage scenarios and known existing infrastructure. Include the basis of each count, the periods when tasks overlap and the questions that need technical assessment. A concise, dated worksheet is more useful than an unexplained total.
DETIAN’s public service scope covers design, equipment supply, installation and maintenance arranged around the actual site. Use the official contact page to discuss the required assessment, proposal and acceptance scope. This article does not promise a particular capacity, wireless speed, access-point count, delivery date or coverage at an unassessed property. Those matters require the project-specific information and an agreed response.
