Smart Building Service Robots — The Complete Guide to Office Building & Corporate Campus Automation in 2026
At a glance: A 400,000 sq ft campus runs four disconnected service layers: reception, mail and parcel delivery, cleaning, and visit control. On one map, an AOMAN D1 moves 40 kg of mail and catering, an AOMAN G1 hosts visitors from 5 m with its six-microphone array, and an AOMAN C1 scrubs 2,040 m² per hour.
A corporate campus runs four service layers in parallel: reception at the front door, internal mail and parcel delivery between floors, nightly cleaning of offices and common areas, and visitor movement through the building. Each layer has its own staff, its own schedule, and its own budget line — and none of them coordinate. The case for robot automation is not any single one of those tasks; it is that they share one building, one elevator bank and one facilities team, and therefore one orchestration problem.
This guide covers the integration layers, the robot roles for office and campus environments, the procurement questions worth asking before an RFP, and an illustrative economics model. Product figures are AOMAN FUTURE platform specifications; financial figures are examples.
Orchestration, not isolated pilots
Most buildings that have "adopted robots" have adopted one robot in one role: a delivery unit on floor 3, a cleaning unit in the lobby, a reception unit at the desk. A production deployment is the opposite — it treats the building as the platform and the robots as services on it. The difference is three integration layers.
Layer 1: Fleet orchestration
With multiple roles active, machines need a common scheduler: priority when two units want the same elevator, shared charging stations, corridor conflict resolution, and route updates when a floor is blocked. Without a fleet layer, each unit competes for the same infrastructure in the dark. The AOMAN D1, AOMAN G1, AOMAN C1 and AOMAN C2 Pro report into the same fleet dashboard, so scheduling is one system rather than four.
Layer 2: Building systems integration
Three integrations make multi-floor operations possible: elevator control integration so units call and ride without an escort (typically over BACnet/IP or a controller I/O bridge — this is the longest-lead item in most programs, budget it first), access control integration so after-hours routes pass secured doors, and network coverage verification so units stay connected across corridors, stairwells and basement levels. A pre-deployment site survey with a signal map of every operating area prevents the most common failure mode: a unit that loses connectivity mid-route stops where it is — the survey's job is to find those spots before deployment, not during it.
Layer 3: Data unification
Once robot data lands in the same place as building data, correlations appear — cleaning logs that show which floors get the most traffic, delivery routes that reveal underused corridors for HVAC zone adjustments, reception logs that show visitor flow patterns. This is why the platform question is more important than the robot question.
The human layer matters as much as the API layer. Staff who will share corridors with the fleet need the exceptions defined in advance — what to do when a unit is stopped, whom to call, where the units are not allowed. A one-page guide and a named robot line of contact is the configuration that prevents the hallway-decoration outcome, because machines stay useful only while somebody owns their exceptions.
The roles: three units, three shifts of value
Delivery — AOMAN D1
Internal logistics — mail, parcels, documents, catering carts — is the most concrete entry point. The D1 carries 40 kg per run on a four-tier tray, clears 70 cm corridors, and navigates the building on the shared SLAM map. One unit supports morning and afternoon scheduled runs from the mailroom, with on-demand dispatch to floors when a parcel arrives or a meeting needs catering. The payload per run is the design constraint: a cart of bulk supplies is a pallet job; the recurring, modular, schedule-bound delivery work is the robot's job.
The unit's 21.5-inch screen also serves the building: tenant notices, event schedules, wayfinding prompts for moving staff or visitors between floors.
Cleaning — AOMAN C1, with AOMAN C2 Pro for compact zones
Contract cleaning of a large building is labor-dominated: hard floors are the part machines can own. The C1 scrubs 2,040 m² per hour with a 790 mm squeegee and carries 70 L fresh water plus 50 L recovery — roughly 16,320 m² of common-area hard floor in a programmed 8-hour overnight shift, which is the lobby, corridor, cafeteria and conference floor of a typical 200,000 sq ft office building. Carpeted offices stay with people; the machine owns the hard-floor common areas, and the crew's contract shrinks to the part machines cannot do.
For smaller zones — kitchenette areas, server-side corridors, executive suites — the C2 Pro fits beneath 70 cm work surfaces, passes 85 cm aisles, and runs quietly with modular tanks that swap at a cleaning closet.
Reception and guidance — AOMAN G1
The reception desk is the highest-appearance-cost point in the building. The G1 handles the recurring visitor flow — who you are, whom you are here for, where to wait, how to get to a floor — with a six-microphone array at 5 m pickup, multilingual guidance, and a 13 MP camera so a human on the desk can watch and take over on complex cases. It assists with check-in workflows, shows the way to meeting rooms, and returns to its dock to charge on its own.
The pattern question is whether the G1 is the primary desk or a supplement. Buildings with pre-registered, predictable visitor flow deploy it as the first point of handling with a human backup; buildings that receive lots of walk-in traffic use it to reduce queue length at the desk and to escort visitors rather than staffing a second desk. Either way, it is a guide that walks with the visitor, not a sign.
Depot, water and power: the planning line item
A campus fleet needs a depot: a place where units dock overnight, where the C1's 70 L fresh tank refills and its 50 L recovery tank empties, and where the spare set lives. The depot should sit in the same building as the largest overnight route, with a few square meters of floor and a standard outlet per unit. It is a small line item and the most commonly forgotten one — cheap to build, expensive to retrofit, and impossible to substitute in week 6.
Sequencing: one building, then the campus
Campus rollouts work in that order because every subsequent building reuses the template: the maps, the elevator integration profile, the depot layout, the staff briefing. After the first building, a second site is a copy operation with site-specific edits — the marginal cost per site falls while the dashboard's fleet view gains the cross-building picture that facility leadership actually reads.
The procurement questions that matter
Before issuing an RFP, have answers to these points — they are ordered by the cost of being wrong:
- One platform or several? If a vendor needs separate dashboards per unit type, the integration work lands on your IT team. Require a single fleet manager across the roles.
- What elevator controllers has the vendor actually integrated? Ask for the controller models your building runs plus a reference site; "we can integrate with anything" is not a scoping answer.
- Is a site survey included? Signal coverage across the operating route and a documented map should be in the deployment fee from day one.
- How are elevator conflicts resolved? When two units want the same cabin at 2 AM, who wins? A configurable priority matrix is the correct answer.
- What is the 3-year TCO line item? Hardware, licensing, integration, maintenance and service per unit, in one table.
- What is the platform security posture? Ask for the certifications held by the cloud platform and documented network segmentation for any on-premise install.
- What is the SLA? A single-unit pilot tolerates slow repairs; an 8-unit building cannot. Require remote response within hours and on-site service within a day.
- Who runs the deployment? Building-wide rollout is a project: elevator integration, access control, network remediation, staff training. The program owner should have done this before.
The economics: an illustrative example
For a 400,000 sq ft campus, the skeleton below is an illustrative calculation — the lease and labor numbers must come from your quotes and payroll.
| Role | Illustrative configuration | Offset |
|---|---|---|
| Internal delivery | 2 × AOMAN D1 | Mailroom run labor plus the floor-by-floor hand-carry loop |
| Hard-floor cleaning | 1 × AOMAN C1, overnight | Common-area hard-floor portion of the cleaning contract |
| Compact-zone cleaning | 1 × AOMAN C2 Pro | Kitchenettes, suites, server-side corridors |
| Reception & guidance | 1 × AOMAN G1 | Queue time at the desk in peak arrival windows |
Model it per line: hours absorbed versus lease cost, and the fixed-cost schedule the fleet preserves. Most campuses find the case is about service continuity as much as payroll — an overnight machine that does not call in sick, a reception layer that stays at full attention at 8 AM Monday. Compare that against the current cost of the same reliability.
New construction or a major renovation improves the case — elevator integration, charging wiring and network drops fold into the build instead of retrofits. For the technology beneath all roles, see the SLAM navigation overview, and for packaging the campus program, the corporate office industry page.
Tell us your building size, headcount and current service layers — we will return a fleet proposal, an integration scope and indicative pricing within 24 hours. Request pricing.
