Astreya Enterprise System (AES) Platform

AES is the internal enterprise operations platform Astreya uses to run its global managed-services business, coordinating a 1,500+ person technical workforce and 400+ field technicians across 500+ buildings in five regions (NAMER, Bay Area, EMEA, LATAM, APAC). Before AES, the operation ran on a patchwork of spreadsheets, email threads, and disconnected legacy tools, with supply, demand, scheduling, inspections, inventory, and performance data all living in separate systems.

The project set out to replace that patchwork with a single web application organized around a persistent left navigation (Applications, Reports, and Back Office). From one interface, operations leaders would forecast and rebalance workforce capacity, dispatch and track field service tasks, schedule technicians against buildings, inspect facilities and flex desks, reconcile IT inventory, audit service quality and compliance, and administer the organizational hierarchy and permissions governing the entire suite.

Astreya runs one of the most complex managed-services footprints in the industry: 400+ field technicians and a 1,500+ person workforce servicing 500+ buildings across five regions. Running that operation on spreadsheets, email, and siloed tools produced the same failures across every part of the business.

There was no real-time visibility, so some regions and buildings ran at 112% utilization with overloaded, burnout-prone technicians while others sat idle at 55 to 63%, and 3,000+ daily tickets (700+ unassigned, 600+ pending) had no single pane of glass. Operations were reactive rather than proactive, PTO tracked separately from schedules made leave conflicts and last-minute coverage scrambles routine, and workflows were manual and error-prone with 108,000+ missed flex-desk inspections accumulated. Governance was fragmented, with no central way to control who could access which tool at what level, producing onboarding bottlenecks and over-provisioned permissions.

I designed all 22 modules as one integrated platform rather than a set of point tools. Every module shares the same navigation, design language, and organizational hierarchy, so data flows across capacity planning, dispatch, scheduling, inspection, inventory, quality, and administration without a user ever leaving the app.

Each module was framed by the specific decision it needs to make possible. Capacity Management (Today, Forecast, Throughput) turns five regional data streams into live and forecasted single-pane views, with an Astral conversational AI layer on top that reads the data and returns ranked recommendations. Field Service Management makes the SLA the organizing principle for both the dispatch dashboard and the technician queue. Team Management makes coverage legible with a staffing-ratio grid and PTO-safe scheduling. The inspection, asset, quality, and back-office modules (AV Inspection, Flex Desk, Building Management, Cycle Count, SLoc, Service Catalog, Audit Tool, QC Tool, and the config hubs) each replace a manual workflow with a status-driven, auditable one.

Designing 22 modules as one product only worked because of shared primitives. The navigation, hierarchy, drill-down, filter and preset systems, and status lifecycles carried consistency that no amount of per-screen polish could have. The investment in a common foundation paid back on every module that followed.

Framing each module by the single problem it removes kept an enormous scope disciplined. Starting from what decision a screen has to make possible, rather than what data it could show, is what kept 22 dense operational tools focused instead of cluttered.