Red flags in an MSP proposal for a commercial real estate company include vague service boundaries, response promises without measurable terms, pricing that overlooks building devices, and no plan for security or equipment lifecycle. Before signing, require a written scope that identifies who owns each system, how incidents are escalated, what is included in the fee, and how the provider will keep property technology documented.
Does the proposal define who owns each building technology system?
A commercial property may have tenant networks beside landlord systems, carrier equipment in the same MDF, cameras on a separate network, and building-system connections maintained by another vendor. A proposal that simply says "we manage IT" leaves important boundaries unsettled until a change or outage exposes them.
Look for a written scope that distinguishes landlord, tenant, carrier, and third-party responsibilities. It should identify who maintains network equipment, access-control panels, cameras, building-system connections, internet service, and cabling. If the MSP is not responsible for a system, the proposal should name the responsible party or explain how that relationship will be coordinated.
Ask how the provider will document dependencies, demarcation points, and escalation contacts. Who approves a change to shared network equipment? Who contacts the carrier when a handoff fails? If the proposal cannot answer those questions, the gap is an operating-model risk, not a minor wording issue.
A useful scope makes clear whether the MSP administers a system, supports its network connection, coordinates with its vendor, or has no responsibility for it. These distinctions matter when property staff need to make a decision quickly and avoid conflicting instructions from multiple providers.
For every connected system, the proposal should state whether it is included, excluded, or coordinated with another provider.
A clear ownership map prevents building operations from depending on assumptions.
Are the service levels measurable and useful to property operations?
"Fast response" is not a service level. The proposal should define when the response clock starts, what counts as a response, how severity is assigned, and whether the commitment covers acknowledgement, active remote work, onsite dispatch, or resolution. Those are different outcomes, and a promise about one does not guarantee the others.
Check whether priority definitions reflect property impact. A tenant unable to access a suite, a camera system that has stopped recording, and an employee's printer issue may have very different consequences. The proposal should explain how the provider classifies incidents and who can request a higher priority or escalation.
Review coverage hours, after-hours procedures, holiday handling, and limits on onsite support. Do not assume that security monitoring means a technician will arrive onsite at any hour. The proposal should distinguish monitoring, help desk support, incident response, and field service so the property team knows what action to expect.
Ask how the provider will communicate during a cross-vendor incident, such as a carrier outage that affects tenant connectivity while building systems remain online. Look for an escalation path, a named point of contact or role, and a clear approach to keeping property staff informed as the issue develops.
Compare service commitments using the same definitions across proposals. A shorter acknowledgement target may not be better if it does not say what happens next. Ask for the written process for priority changes, unresolved issues, and incidents that affect multiple tenants or shared systems.
Useful service levels describe actions and accountability, not just reassuring adjectives.
Does the pricing model account for properties, devices, and project work?
A per-user fee may be easy to compare, but a commercial property can have many network-connected devices and relatively few staff accounts. Cameras, access-control equipment, wireless access points, intercoms, building-system connections, and shared amenity systems can create support and security work that a headcount-based proposal does not explain.
Ask what the recurring fee includes and what is billed separately. Clarify whether these items are included, excluded, or available for an additional charge:
- Onboarding and documentation
- Site visits and after-hours work
- Vendor coordination and project management
- Tenant move-ins, suite turn-ups, and equipment replacement
Look for the assumptions behind the quoted scope: number of sites, supported devices, network equipment, user accounts, service hours, and existing documentation. If those assumptions do not match the property, the monthly fee may not represent the cost of the support model the business actually needs.
Separate recurring managed services from project work and capital purchases. The proposal should explain how estimates are prepared and approved, how out-of-scope work is handled, and who owns replacement decisions. Treat a low headline fee cautiously if the provider has not explained what is left out.
Before comparing prices, give each provider the same site and device information and ask them to identify assumptions in writing. That makes it easier to see whether proposals cover comparable responsibilities rather than simply presenting different monthly totals.
Transparent assumptions make the proposal easier to budget and compare.
Does the security scope cover connected property systems?
Cybersecurity language can sound comprehensive while applying only to employee computers and email. Ask whether the proposal identifies network segmentation, administrative access, vendor remote access, firmware and patch responsibilities, backups, and incident escalation. It should also specify which building systems are in scope and which remain with their equipment vendors.
A general promise that the environment will be "secure" is not a substitute for named controls and responsibilities. The proposal should say what is monitored, what events are escalated, who can authorize containment actions, and how the property team is informed when a response could affect tenants or building operations.
Ask how the provider handles systems it cannot administer directly. A camera platform or access-control controller, for example, may be maintained by a specialist vendor. The plan should establish a contact path and a way to coordinate changes without implying that the MSP controls every system.
Clarify how security decisions are made when containment could interrupt a shared service. The contract or operating plan should identify who has authority to approve disruptive actions, how urgent risks are communicated, and what the provider will document after an incident. Clear decision rights help the property team balance risk reduction with continuity.
Ask what evidence the provider will deliver, such as an asset inventory, network diagram, access review, backup status, or incident record. The deliverables should match the contracted scope. If a proposal promises protection but says nothing about reporting, ownership, or follow-through, ask for specifics before signing.
Security is credible when the proposal names controls, boundaries, and decision owners.
Will the provider document the building and plan for its technology lifecycle?
A proposal that starts with tools but skips discovery may miss the building's actual condition. Ask how the provider will record MDFs and IDFs, switches, wireless coverage, carrier demarcations, riser pathways, system owners, and known dependencies. The initial inventory should distinguish verified information from assumptions that still need confirmation.
Documentation matters during tenant improvements, acquisitions, outages, and vendor changes. It should be maintained as the environment changes, with a clear owner and a defined process for property staff to request corrections. A diagram delivered once and never updated is a snapshot, not a reliable operating record.
Ask whether the proposal includes lifecycle reviews for network, camera, and access-control equipment and how findings translate into a phased budget. The provider should distinguish equipment that needs replacement from equipment that may remain supportable through better documentation, configuration, or clearer ownership.
Look for a discovery and transition plan that explains what the provider will inspect, what access it needs, and how it will handle unknowns. If important records are missing, the proposal should describe how those gaps will be identified and prioritized rather than presenting assumptions as confirmed facts.
Therese, a commercial real estate client, described the value of understanding an issue and preventing it from recurring: "Brian clearly explains what is happening and shows you ways to help prevent the issue from happening again. He is great to work with." That is a useful standard for evaluating communication: the provider should explain the issue and the practical next step.
GDS Technology supports commercial real estate technology needs through services for commercial real estate, including work that can span IT operations and physical technology infrastructure. Its riser management services address a part of the building environment that should have a clear owner and documented process.
Documentation turns inherited complexity into something the property can govern and budget.
Frequently Asked Questions
What is the biggest red flag in an MSP proposal for commercial real estate?
The biggest red flag is a broad promise to manage "IT" without defining the systems, sites, and responsibilities included. Commercial properties often involve landlord infrastructure, tenant networks, carriers, security systems, and specialist vendors. Require a written scope, ownership boundaries, escalation process, and documentation plan before comparing proposals.
Should an MSP proposal include cameras, access control, and building systems?
It should state whether those systems are included, excluded, or coordinated with their specialist vendors. Do not assume that managed IT automatically covers cameras, access control, or BMS connections. Ask who administers each system, who handles network dependencies, and how changes or incidents are escalated between the responsible parties.
How can a property team compare MSP response times?
Compare defined service commitments, not phrases such as "rapid support." Check the clock start, severity levels, acknowledgement and action expectations, service hours, onsite dispatch terms, and escalation path. Confirm how the provider handles incidents that affect tenants or shared building systems and how the property team receives updates.
What documentation should an MSP provide for a commercial property?
Ask for a maintained inventory and diagrams covering supported network equipment, MDFs and IDFs, carrier demarcations, key dependencies, system owners, and escalation contacts. The exact deliverables should match the contracted scope. Establish who updates the records after changes and how the property team can report corrections.
How can a CRE company avoid surprise charges in an MSP contract?
Review the assumptions and exclusions behind the recurring fee, including sites, users, devices, service hours, onboarding, onsite work, vendor coordination, projects, and tenant changes. Ask how out-of-scope work is estimated and approved. A written schedule of included services and additional charges is more useful than a low headline fee.
