Office Pod Occupancy Controls: What Should Lights, Fans and Sockets Do?

When comparing automatic ventilation adjustment for an office pod, ask what detects occupancy, what equipment that signal controls, and what happens while a person sits quietly or briefly leaves. A light coming on when the door opens does not establish how the fan operates. The most useful buying specification describes the behavior of each system, rather than simply requesting a "smart pod."

For facilities teams, dealers and workplace designers, start with the activities the pod must support. A short standing call, a quiet reading session and a meeting using shared equipment create different control questions. Decide which actions users should take themselves, which the proposed equipment can perform automatically, and who can change the settings after installation.

Glazed meeting pod with a table and chairs beside an office circulation area
Product-setting reference showing seated workspace beside a circulation area. The image does not identify a sensor, demonstrate control behavior or establish a supplied equipment package.

Specify the trigger, the action and the return condition

Break an automatic-control proposal into three parts. The trigger might be a manual command, a detected presence, a door event or an environmental input. The action might switch a light, select a fan mode or change a permitted outlet state. The return condition explains when that action ends and what happens next.

Those parts need not be shared by every device. A proposed lighting delay, for example, should not silently become the ventilation setting or disconnect equipment that users expect to remain powered. Ask the supplier to identify the controlled loads separately and explain any dependencies between them.

For lighting terminology, Eaton's occupancy and vacancy sensor documentation distinguishes automatic-on/automatic-off operation from manual-on/automatic-off operation. This is an example of a manufacturer's lighting-control terminology, not a statement that these components are installed in MobileX products or suitable for switching a pod's fans and outlets.

Compare control approaches against the work

The alternatives below are requests to evaluate for a particular configuration. Their availability, compatibility and implementation need confirmation from the responsible supplier.

Scroll horizontally to compare all columns.

Proposed approach Where it may fit the intended use Question that changes the decision
User switches the relevant function on and off A simple, clearly managed setup where users can reach and understand the control Who restores the ready state when someone forgets, and which functions remain available during use?
Manual-on with automatic-off for a named load Users choose when to start that function, with an agreed response after detected vacancy Can quiet seated activity be recognized, and can the user recover without disrupting the task?
Automatic-on and automatic-off for a named load Frequent arrivals where reducing a routine user action is useful Can nearby movement or an open door create unwanted activation, and what is the actual detection area?
Presence-linked fan operation with an agreed run-on A supplier-designed arrangement that accounts for occupied and post-use operation What operating state applies after exit, what ends it, and how is suitable occupied ventilation established?
Environmental-input control proposed by the supplier A project with documented sensors, control logic and a competent system review What is measured, where, how is it maintained, and what happens if the signal is unavailable?

Prefer the simplest arrangement that meets the use requirement and can be supported by the operator. More automation is not automatically a better fit. Conversely, a manual system needs an operating plan; a switch alone does not ensure people will use it as intended.

Keep ventilation requirements separate from presence detection

Ask whether a proposed signal means that movement was detected, that a person is believed to be present, or that an environmental condition was measured. These are different inputs. A door opening can start an event without telling the controller how many people remain inside. A booking ending is an administrative event, not confirmation that the pod is empty.

For a ventilation proposal, have the supplier describe the occupied mode, any post-use mode and the condition for returning to the ready state. The appropriate behavior must be tied to the pod, its air path, intended use and the surrounding building. Do not select an arbitrary delay and treat it as evidence that ventilation is adequate.

The MobileX ventilation guide explains the distinction between component measurements and installed-pod performance. Use it to frame the evidence request. This article addresses control behavior, not a new airflow claim or a model-specific control specification.

If a CO2-based proposal is offered, request the measurement and control documentation rather than assuming a displayed number proves performance. HSE's guidance on CO2 monitors describes measurements as a broad guide to ventilation, cautions against isolated readings, and explains limitations when occupancy changes. It is UK workplace guidance, not a pod certification or a universal control threshold. Ask a suitably qualified reviewer to assess whether the proposed input and operating logic are appropriate for the actual installation.

Check a quiet user and a busy doorway

A useful supplier demonstration includes the actual seating arrangement, screen position and door use. Watch how the proposed system responds when someone is reading or listening without large movements, when another person passes outside, and when one participant leaves a meeting while another stays.

Record the observed behavior of the light and fan separately. Ask the supplier to explain whether each result is expected for that device, placement and configuration. If the system interrupts the task, consider changing the proposed detection arrangement, the control strategy or the equipment choice. Do not make users compensate for an unsuitable system by repeatedly waving at a sensor.

This is a functional procurement demonstration, not ventilation, electrical-safety or acoustic certification. The supplier and appropriate professionals should arrange any technical tests and settings changes. Buyers should not defeat safety functions or open electrical enclosures to investigate the result.

Decide what happens to connected equipment

List shared screens, chargers, docking equipment and other devices that may remain connected. For each, say whether it belongs to the user or the facility and whether its power state is expected to change when the pod becomes vacant. Ask the electrical supplier to confirm which outlets, if any, are controlled and how they are identified.

A user leaving should not create an undocumented consequence for the next session. For example, a shared device may need time to restart, or the operator may want a particular device to remain available between bookings. The device supplier and site team must confirm the acceptable arrangement. There is no assumption here that a pod includes always-on outlets, a switched socket circuit or any particular control interface.

For physical connections and site work, use the installation and electrical checklist. For equipment used during a call, use the video-call configuration guide. These decisions should inform the control request before equipment is ordered.

Make settings and exceptions manageable

Separate everyday user adjustments from settings reserved for the operator or service provider. Ask who can change a delay, select a mode, restore a configuration or report a fault, and how the final settings are documented. Request an explanation of the behavior after a power interruption and after any control-system restart.

If a connected controller is proposed, identify whether normal operation depends on a network, account, subscription or external service. Request its supported behavior when that dependency is unavailable. Keep any data collection proportionate to the operating need; a simple control requirement is not a reason to collect conversations or identifiable activity histories.

For a MobileX enquiry, state the required behavior and ask which functions are included, optional, provided only as an interface, or outside the quoted supply. Do not treat a generic reference to smart controls as confirmation of sensor availability, network integration or ongoing software support. A proposed component change also needs the supplier's review of electrical compatibility, access and support scope.

Use a short scenario sheet to compare proposals

Give each shortlisted supplier the same scenarios. Complete the sheet with proposed behavior first; record observed results only after a demonstration of the identified configuration. The table is a buyer's tool, not an existing MobileX test record.

Scroll horizontally to compare all columns.

Scenario Describe separately for lighting, fans and relevant outlets Record or request
First arrival Which user action or signal starts each function? [Trigger, device and initial state]
Quiet seated work What keeps the intended functions operating? [Task, seating arrangement and observed response]
One person leaves while another stays Does the remaining user retain the required operation? [Detection arrangement and explanation of the result]
Brief exit followed by re-entry What remains on, what changes, and how does the session resume? [Return behavior and any interruption]
Final departure Which functions stop, remain available or enter a documented post-use mode? [Condition for ending that mode and returning to ready]
Passage outside or a door left open Can external activity change the intended state? [Placement review and proposed response]
Operator servicing or a control fault How is the pod marked unavailable, inspected and returned to use? [Responsible party and applicable instructions]

Do not fill gaps with assumed settings. An unanswered condition is a specific item for the supplier, equipment provider or site operator to resolve. Keep functional observations separate from formal technical evidence.

A shared pod can need different behavior between sessions

Consider a hypothetical meeting pod used for quiet laptop work in the morning and short team discussions later. A lighting strategy that works for people entering and talking may not suit a person sitting still. At the same time, the operator may need shared equipment ready for the next session while ventilation follows its own agreed post-use sequence.

The purchasing choice is therefore about separate behaviors, not a single master "occupied" switch. Compare whether a simpler user-operated lighting arrangement, a different detection proposal or another supported configuration meets the tasks. If none does, choose a different equipment package or discuss a custom interface before committing to the order.

Use the booking and handover guide for availability and operator responsibilities. Once actual modes are defined, the energy-budget guide can organize power and operating-time inputs. Neither a sensor label nor this hypothetical example establishes energy savings.

Send a behavior brief with the configuration enquiry

Start with the office pod range or a custom modular pod discussion. Include the following details with the enquiry:

  • Intended tasks and users: [quiet work, calls, meetings and typical changes of occupancy]
  • Proposed model and layout: [seats, screens, doorway and nearby circulation]
  • Required behavior: [separate lighting, fan and outlet states]
  • User and operator adjustments: [what each should be able to change]
  • Connected equipment: [device list and expected between-session availability]
  • Site dependencies and unresolved questions: [power, network, building services and responsible parties]

Send the brief to MobileX POD to discuss a configuration and its supply boundary. Ask for written confirmation of the supported functions and any work or equipment that must be arranged separately. That gives the buyer a useful comparison before selecting controls, without turning an unverified automation option into a product promise.