What to review when your software team works at customer sites

Customer-site implementation and mobile support can bring contracts, access rules, travel, and equipment into a coverage conversation.

Prepare a factual picture of off-site services before seeking or renewing coverage.

Priya Sharma · Workforce and operating changes 6 min read

Direct answer

What to review when your software team works at customer sites

Customer-site implementation and mobile support can bring contracts, access rules, travel, and equipment into a coverage conversation. Start with “Define the work away from your office,” then use “Collect site and contract requirements” to compare the relevant issued documents. The answer turns on that page-specific record, not a policy label alone.

Compare the question with the issued documents

Article-specific review stepRecord to bring forwardDocument comparison
Define the work away from your officeThe facts, timeline, operating record, and correspondence identified in “Define the work away from your office”The definitions that describe the activity, property, service, or event addressed there
Collect site and contract requirementsThe declarations, forms, endorsements, and agreement identified in “Collect site and contract requirements”The exclusions, limits, deductibles or retentions, dates, and conditions that control that section
Compare the policy detailsThe open item, responsible person, deadline, and supporting record identified in “Compare the policy details”The notice, consent, cooperation, and reporting instructions tied to that next step
Decision path for What to review when your software team works at customer sites: Define the work away from your office, Collect site and contract requirements, and Compare the policy details.What to review when your software team works at customer sitesDefine the work away from your officeStart with this recordCollect site and contract requirementsRead the controlling termsCompare the policy detailsDocument the next step
What to review when your software team works at customer sites: a practical saas, technology e&o, cyber, and customer-contract insurance guidance review path.

Questions related to What to review when your software team works at customer sites

What does “Define the work away from your office” mean for What to review when your software team works at customer sites?

Use the facts and records identified in “Define the work away from your office” to describe the actual event or business change. That record gives the policy review a specific starting point instead of treating What to review when your software team works at customer sites as a generic category.

Why compare “Collect site and contract requirements” for What to review when your software team works at customer sites?

The relevant definitions, exclusions, limits, conditions, and policy dates must be read against the facts. “Collect site and contract requirements” identifies the document-level comparison needed before drawing a conclusion.

What follows from “Compare the policy details” for What to review when your software team works at customer sites?

Record the documents checked, the unresolved item, the person responsible, and the next deadline. The process in “Compare the policy details” creates a usable follow-up for this specific question.

Continue the review

Operations

Define the work away from your office

Capture who visits customer locations, what they do there, whether they handle customer equipment, and whether work is recurring or project-based. A remote software team and an onsite implementation crew present different operational details.

A customer-site visit may involve only training, or it may include installation, testing, access to facilities, use of equipment, and coordination with a customer’s vendors. Describe the actual scope and frequency instead of calling all offsite work “support.”

Create an intake step for new deployments: location, customer industry, access requirements, people attending, equipment involved, travel method, third parties, and contract requirements. It produces useful facts before the work begins.

Collect site and contract requirements

Keep customer site rules, certificates requested, statements of work, and any requirements involving additional insured status. Ask whether a venue or client is asking for evidence only or a specific endorsement.

Customer site rules can address visitor conduct, safety, security, access credentials, and proof of insurance. Store them with the statement of work so the project team can follow the same conditions the contracting team reviewed.

If a client requests a certificate or endorsement, verify the requesting entity and the exact clause. A parent company, property manager, or project owner may have a different legal name and role than the day-to-day customer contact.

Compare the policy details

Review territory, premises and operations wording, professional-services exclusions, hired or non-owned auto considerations, and equipment terms where relevant. The right question depends on the work, not the phrase “mobile services.”

Offsite operations can raise separate questions about general liability, professional-services exclusions, hired or non-owned auto, employer obligations, property in the company’s care, and territory. Which questions matter depends on the facts and issued terms.

A travel policy, driver list, equipment log, and subcontractor roster can be as useful as a coverage schedule when preparing a renewal or responding to an underwriter’s follow-up questions.

Set a check-in point

Document each new service model and revisit it at renewal or before a large deployment. Ask which locations, travel patterns, subcontractors, and contractual obligations have changed. Policy wording, declarations, and endorsements control.

For material projects, schedule a short pre-deployment review with operations, legal, and the broker. Confirm the customer’s request, service scope, certificate deadline, and any change in the company’s representations.

Do not infer coverage from a certificate, project plan, or prior deployment. Policy wording, declarations, endorsements, and the actual facts control.

Turn a site visit into a documented work scope

Before a deployment, identify the customer site, dates, people attending, task list, equipment handled, systems accessed, and whether a subcontractor is involved. Separate a meeting or training visit from installation, testing, troubleshooting, or physical work. The contract and site rules may describe duties differently from an internal project ticket, so compare them before the team arrives.

Record who supplies and controls equipment, whether employees use their own vehicles, and whether sensitive customer information can be accessed from the site. These details guide questions about general liability, professional liability, property, hired or non-owned auto, workers’ compensation, and cyber, but they do not by themselves establish that any policy responds.

Check the customer’s access and insurance rules

Ask for the site-access agreement, statement of work, insurance exhibit, certificate request, and any safety or information-security rules. Confirm the legal entity requesting evidence and the deadline. A property manager, customer subsidiary, and project owner may each have a different role. If additional-insured status or other endorsement language is requested, compare it with the relevant issued form; a certificate alone cannot create the status.

Build a pre-visit checklist covering site contact, scope, access credential owner, device rules, data-handling requirements, incident contact, approved subcontractors, and document owner. The checklist helps operations meet the agreement and helps the insurance reviewer see the actual exposure.

Example: implementation at a customer facility

Suppose two employees visit a customer facility to configure an integration and test data transfer. One brings company equipment; the other uses a personal vehicle. The work may involve customer systems and customer property, as well as the risk of an incorrect configuration. Those are separate questions. The review should identify the tasks and property, the vehicle use, the service promise, and who controls the credentials before selecting forms to examine.

If the project later expands into ongoing managed support, revisit the submission and contract. A short visit and a continuous onsite obligation are not the same operating model. Preserve the change order, new work schedule, and any updated certificate or endorsement request.

Post-visit records and renewal triggers

Keep the final work order, visitor or safety requirements, certificate and endorsements delivered, equipment log, subcontractor records, and any incident report. If work causes a customer complaint, preserve the original communications and seek prompt fact-specific notice guidance under the policy. Do not decide a notice deadline from memory.

At renewal, count how often teams work onsite and whether the tasks have changed. The frequency, customer types, equipment, travel, and data access belong in the current operating description. Policy wording, declarations, endorsements, actual facts, and applicable law control.

Who should approve a changed deployment

The project lead can confirm work scope and site rules; security can assess access and data transfer; legal can review contract changes; people operations can verify staffing and travel practices; and the insurance owner can compare the updated facts with the policy file. Give one person responsibility for recording the outcome and unresolved items. This avoids a certificate request being handled in isolation from a material change in the actual work.

If the customer changes the location, entity, or scope after documents are issued, do not assume the original review travels with the project. Check the revised request and retain the new decision record.

Sources

Get insurance ready for your next contract.

Tell us what you sell and when you need coverage. We will work through the requirements and start building your insurance submission.

Discuss business insurance