For current-system operators and authorized service contactsExisting CustomerCurrent servicePlain-language page

Check Whether Building Automation Systems Can Support Your Request

  1. 01 · Current issue

    Visitors need a direct decision on location, system, urgency, and service fit.

  2. 02 · What is affected

    A request routed without location, system, consequence, access, and timing facts can reach the wrong service class or remain unserviceable.

  3. 03 · Support path

    A company-level path to check location, building conditions, urgency, access, and available support.

  4. 04 · Information that helps

    Confirm the request type, current offer status, service boundary, routing requirement, and the person responsible for follow-up.

05 · Get help

Start with the building concern and desired outcome. System terms appear only when they help the next decision.

A human review confirms scope, service area, access, authority, timing, and responsibility before work is scheduled.

Support boundary: Availability depends on project fit, service area, access, staffing, authority, and a written agreement.

Illustrative closeout record with test windows, verifier, open limitations, and a persistence follow-up date.
Concept composition — no live data

Illustrative closeout—not a customer result, case study, warranty, or measured savings claim.

Verified authority and honest boundaries

Representative operating context supports the mission without inventing staff, locations, customers, or completed projects.

Support path

Share the condition, consequence, and safe access details

A human review confirms scope, service area, access, authority, timing, and responsibility before work is scheduled.

01

Check immediate responsibility

Choose the building problem, product decision, support need, or learning goal.

02

Gather useful history

Provide the minimum useful context without sharing credentials or confidential site information.

03

Route the next action

Receive a prepared local summary and the correct human-routing requirement for future integration.

What to keep

A clearer issue record for the people doing the work

Keep timestamps, symptoms, recent changes, access limits, and open responsibility together.

01

Clear responsibility and next contact path

02

Truthful current-versus-planned status

03

Published limits and evidence requirements

Useful evidence

Give the support team enough context to choose the next safe action

Confirm the request type, current offer status, service boundary, routing requirement, and the person responsible for follow-up.

  • Location
  • Building and system context
  • Consequence, access, and requested service class
Three technical workers discussing equipment in an industrial work area.
Representative photograph — not Building Automation Systems work

Representative technical collaboration—not a building automation system (BAS) team or customer meeting.

Support boundary

Availability depends on project fit, service area, access, staffing, authority, and a written agreement.

Support outcome

Reach the right support path with less back-and-forth

Useful context helps the service conversation start closer to the actual problem.

01

Avoid false expectations and prepare the information needed for the appropriate response path.

02

Problem-specific routing reduces back-and-forth and sends each request toward the most relevant next step.

03

Explicit current, planned, and unconfirmed facts keep expectations honest before public launch.

Interactive local workflow

Service qualification

Coverage is not assumed. Prepare location, consequence, access, and service needs for human qualification.

Local-only: this prepares a summary. It does not transmit a lead.

Take the next useful step

Start a Coverage Review