# What Should Teams Include in a Utility Software RFP in 2026?

vuti.app · September 27, 2026

> Direct Answer: What Belongs in an RFP for Utility Software? A utility software RFP should define the operational problem, required workflows, security...

## Direct Answer: What Belongs in an RFP for Utility Software?

A utility software RFP should define the operational problem, required workflows, security controls, implementation responsibilities, acceptance criteria, and total cost before it asks vendors to propose a product. For facilities and workplace teams, the document must connect virtual-utility records to practical work such as vendor onboarding, utility-bill validation, service-request tracking, compliance evidence, invoice exceptions, and management reporting. It should not simply list attractive features or name a preferred vendor.

**Also worth reading:** [How Do You Compare the Total Cost of Ownership of Utility Software in 2026?](https://vuti.app/knowledge/how_do_you_compare_the_total_cost_of_ownership_of_utility_software_in_2026.php) · [What Is the Best Utility Software RFP Checklist for Vendor Operations?](https://vuti.app/knowledge/what_is_the_best_utility_software_rfp_checklist_for_vendor_operations.php) · [How Do Organizations Buy Utility Software Without Creating Procurement Risk in 2026?](https://vuti.app/knowledge/how_do_organizations_buy_utility_software_without_creating_procurement_risk_in_2026.php)

A useful RFP normally contains four connected parts: a statement of current conditions, measurable future requirements, a transparent process for evaluating responses, and legally and commercially complete contract terms. The 2026 version should also address data portability, AI usage, third-party integrations, business continuity, accessibility, and what happens when a provider changes ownership or discontinues a service. These subjects matter because software selection is an operating decision, not only a technology purchase.

Teams should allow enough time for vendors to ask questions, prepare demonstrations, review security material, and submit accurate pricing. For a mid-sized organization, a realistic procurement cycle is often 8 to 16 weeks; complex multi-site or regulated deployments can require 4 to 8 months. The timeline should begin with business requirements rather than a fixed feature grid, and it should reserve at least two weeks for final validation and contract review. A rushed process often produces an attractive presentation but weak operational fit.

Finally, the RFP should require evidence. Statements such as “secure,” “scalable,” or “easy to use” are not useful acceptance criteria unless the vendor explains how those claims are measured. Examples include a defined uptime target, a documented recovery-time objective, named implementation resources, sample data-migration plans, and service-level remedies. The purpose is not to eliminate judgment; it is to make judgment based on comparable evidence.

## Core Requirements for Virtual Utility and Vendor Operations

Start with the outcomes the system must support, such as reducing invoice-processing time, improving capital-project coordination, maintaining complete service records, or producing reliable reports across several buildings. Specify the number of sites, vendors, users, invoices, meters, and work orders where known, while allowing vendors to identify assumptions about future growth. If the organization expects 250 suppliers and 1.5 million annual invoices, for example, the RFP should state whether both figures represent current volume or a three-year forecast.

Virtual-utility requirements should cover the shared service model in which participating organizations provide or administer services for sites or business units. Ask how software records service ownership, approvals, charges, credits, and disputes. Require clear separation between authorized requesters, invoice approvers, vendor administrators, financial reviewers, and system administrators. If staff perform a task only during a monthly close cycle, the RFP should account for that cadence rather than assuming daily use.

Vendor-operations requirements should address registration, due-diligence review, insurance and compliance-document expiration, payment-status communication, service requests, incident escalation, and performance reviews. Define which records constitute the official vendor file and where they can be exported. A good system should preserve status history so an auditor can see who approved a supplier, what evidence was current at the time, and when a change occurred. Vendors should demonstrate these controls in a scenario rather than merely describing them.

Also specify reporting and data-quality rules. Reports should reconcile invoices to service records and identify duplicate invoices, unusual price changes, missing documents, and unresolved credits. If the expected accuracy target is at least 98% of matched invoice lines, that threshold should appear in test criteria along with a definition of “matched.” Avoid demanding a generic 100% accuracy claim; most operational data contains exceptions, and vendors should explain how their system distinguishes a true error from an unusual but valid transaction.

## Evaluation Criteria, Weights, and Demonstrations

An evaluation matrix prevents the loudest sales presentation from determining the decision. Establish weights before vendor responses arrive, with a typical distribution of 25% to 30% for operational fit, 15% to 20% for security and privacy, 10% to 15% for implementation and support, 10% to 15% for total cost, and 10% to 15% for data management and reporting. The remaining points can cover integration, usability, accessibility, and service-level performance. Organizations should adjust the weights rather than treat them as universal.

Each criterion needs a measurable score from 1 to 5 and a short reason for the score. For example, a vendor may receive a 4 for invoice workflows if it demonstrates exception handling, configurable approval paths, and exportable audit history, but only a 2 if it offers fixed approval rules without reporting. Mandatory requirements should remain pass or fail; excessive weight cannot compensate for missing identity controls, incomplete data export, or unacceptable contractual terms.

Demos should use scenarios drawn from the organization’s environment. Ask vendors to retrieve one noncompliant vendor record, process a credit, route an invoice above a defined threshold, identify an expiring insurance document, and produce a report covering three sites. Include an exception such as a disputed invoice or a failed integration. Seeing how a platform handles messy data is more informative than watching a polished sample account.

Reference checks should be separate from the sales conversation. Request customers with similar scale and operating complexity, then ask about implementation duration, support quality, unresolved defects, and whether the vendor would choose the product again. Verify claimed results rather than asking only whether a customer is satisfied. A response such as “invoice review time fell from 20 minutes to 8 minutes” is stronger than “the system saves time,” although even numerical claims should be understood in the customer’s original context.

Procurement should publish a schedule that includes shortlisting, scripted demos, reference calls, clarification questions, scoring, and final recommendation. If more than five vendors reach the final stage, use a fixed 45-minute demo, a written response to the same ten questions, and equal access to clarification. This structure improves fairness and reduces unnecessary process.

## Security, Privacy, AI, and Business Controls

Security requirements should be proportionate to the data and deployment. At minimum, ask for encryption in transit and at rest, role-based access control, multi-factor authentication, secure configuration, logging, vulnerability management, patch commitments, tested backups, and documented incident-response procedures. A production uptime target of 99.9% equates to no more than roughly 8 hours and 46 minutes of unplanned downtime over a 365-day year; higher tiers should use approximately 99.95%, which limits such downtime to about 4 hours and 23 minutes annually.

The RFP should request current independent assurance reports, such as SOC 2 or an equivalent control assessment, and identify which controls were covered. A report does not replace the buyer’s risk review, but it can help verify that governance and controls operated during a stated period. Ask how the vendor handles customer requests for penetration testing, subprocessors, data location, and remediation of severe vulnerabilities. Avoid treating a logo on a website as proof of a complete control environment.

AI requirements deserve explicit treatment in 2026. If the product uses AI to classify invoices, recommend vendors, draft service reports, answer search queries, or summarize meetings, require disclosure of intended uses and prohibited uses. The organization should decide whether sensitive financial, employee, or infrastructure data may be used for model training or retention. Contracts should state whether human review is required for consequential decisions, how errors are corrected, and whether explanations and source records can be retrieved.

Business-continuity planning should include recovery-time and recovery-point objectives, backup restoration tests, alternate staffing, and customer communications. A target such as a two-hour recovery time and 24-hour recovery point may be appropriate for a lower-tier administrative service, but critical invoice or compliance systems may need tighter targets. Also require a transition process for termination, including data format, export frequency, assistance period, deletion confirmation, and assistance with migration to another provider.

A 2026 incident may also involve politics, pressure, or disputed relationships. KNKX Public Radio reported on a Bellingham staffer asking ChatGPT to exclude a vendor from a city contract, which illustrates why public-sector buyers need objective, documented evaluation rules. The underlying report does not establish a general software standard, but it shows why informal off-platform prompts must not influence a procurement outcome. Selection criteria, evaluator access, and conflict disclosures should be recorded in the official process.

## Implementation, Data Migration, and Acceptance Testing

Implementation is a contractual work product, not an optional service call. The RFP should request a work plan covering discovery, configuration, data cleaning, migration, integrations, testing, training, go-live, stabilization, and post-launch review. Ask vendors to identify dependencies, customer responsibilities, expected durations, travel or professional-services costs, and the number of named personnel. If a vendor promises an 8-week implementation for a 200-site deployment, require an explanation of what makes that schedule feasible and what could delay it.

Data migration should be tested with representative records rather than a clean sample. Include historical invoices, active and expired vendors, duplicate addresses, mixed currencies, credits, attachments, compliance documents, and incomplete records. Define whether the vendor cleans records, flags issues, or merely loads them. The buyer should approve a migration approach and retain responsibility for source-data decisions where appropriate. A reconciliation report should show expected and loaded counts, rejected records, transformations, and corrections before final acceptance.

Integrations should be named, versioned, and assigned responsibility. Depending on current systems, these may include an enterprise resource planning platform, single sign-on provider, ticketing tool, payment system, data warehouse, or electronic-signature service. State whether APIs are included in the subscription, whether the vendor or customer builds interfaces, and which party bears usage charges. Ask for rate limits, sandbox availability, documentation standards, and notice before material API changes.

Acceptance testing should include objective scenarios and pass thresholds. Examples include loading 10,000 test invoices with at least 99.5% correctly classified records, completing an end-to-end invoice approval within five business days, generating a required report within 60 seconds, and exporting all records in a documented format. Security, accessibility, and disaster-recovery tests may require separate acceptance procedures. Avoid criteria based only on subjective phrases such as “the system is intuitive.”

The contract should state that payment is not the sole basis for acceptance, and it should identify who can reject a failed deliverable. Training should include administrator sessions, role-based user sessions, recordings, reference materials, and at least one post-launch review. A vendor may reasonably refuse to guarantee that every user will adopt the software, but it should guarantee that training materials, support channels, and documented workflows are delivered.

## Pricing and Total Cost of Ownership

Pricing should be requested as a three-year or five-year total-cost model, not only as a monthly license. Ask for per-user, per-site, per-vendor, per-workflow, or enterprise pricing and state which model is being compared. Include implementation, data migration, integrations, configuration, training, hosting, support, premium modules, storage, taxes, and optional services. Specify the billing unit, minimum term, annual increase cap, renewal process, and charges for additional users or sites.

Planning ranges can be useful, but they should not be presented as universal market prices. A smaller vendor-ops deployment may begin in the low thousands of dollars annually, while a multi-site virtual-utility platform with integrations, migration, and implementation can reach tens or hundreds of thousands of dollars over several years. The decisive variables are the number of users, sites, transactions, entities, modules, integrations, service level, data volume, and implementation scope.

For a hypothetical 50-site organization evaluating five competing offers, calculate the three-year cost of each proposal using the same assumptions. A $30,000 year-one price plus $15,000 in annual renewal charges is not equivalent to a $24,000 annual price with implementation costs excluded. Include internal labor for configuration, vendor review, training, invoice exceptions, and change management because software fees rarely represent the full operating cost.

Price protections can be negotiated. Consider a three-year term with annual increases capped at the lower of 3% or a stated inflation index, provided the index and exceptions are defined. Request price protection for new modules, additional sites, and material scope changes. A “free” implementation may be reasonable when standard, but customization should be priced separately; otherwise the organization may lose leverage after go-live.

Exit costs deserve attention before signature. Ask whether data export, account closure, deletion, and migration assistance are included. If the provider charges a termination fee, define whether it declines over time and whether it conflicts with the customer’s contractual termination rights. Total cost should include the risk of rework, but a prudent analysis should not assume failure; it should compare reasonable scenarios rather than assign every possible cost a 100% probability.

## Comparison of Software Procurement Options

Organizations can evaluate platforms directly, use an implementation partner, select a broader suite, or retain a manual process. The right comparison is not necessarily “software versus software”; it is the operating model that best meets requirements at acceptable cost and risk. Vendors should explain the role of the customer, implementation partner, managed service, and software provider. Contracts must avoid gaps such as an implementation partner promising configuration that the software provider does not support.

| Feature | Option A: Point solution | Option B: Broader suite or managed service | Option C: Custom or hybrid model |
| --- | --- | --- | --- |
| Initial fit | Fast for one narrow workflow | Better cross-module consistency | Flexible for unusual requirements |
| Implementation | Often 6–16 weeks | Often 3–9 months | Often 6–18 months |
| Integration | Confirm APIs and add-ons | Confirm included interfaces | Highest control, highest maintenance |
| Data control | Depends on vendor export policy | Broad reporting may help | Strong internal control if well documented |
| Cost pattern | Lower entry cost, possible module fees | Higher total cost, less fragmented buying | High professional-services and upkeep cost |
| Best use | Single-site or limited workflow | Multi-site standardized operations | Specialized needs not supported by standard tools |

The table is a planning comparison, not a vendor recommendation. A point solution can be appropriate when a small team needs invoice validation but not a full virtual-utility platform. A broader suite may reduce reconciliation work when billing, service requests, assets, and vendor management must share one record, but it can also add modules the organization will not use. Custom development should be justified by a durable requirement that standard software cannot meet; it should not be used to recreate routine configuration merely because an internal team can write code.
Manual or spreadsheet-based processes should also be benchmarked honestly. They may be adequate for fewer than 10 sites, low transaction volume, and infrequent reviews, but they become fragile as volume, entities, and compliance obligations increase. The comparison should measure current labor, missed-document risk, duplicate or disputed invoices, and reporting time. A software estimate should not be called a savings case until those baseline numbers are verified.

## Common Mistakes and the Decision Timeline

One common mistake is copying a vendor’s feature questionnaire. That approach favors whichever response form is most complete rather than the system that best fits the operation. Another is mixing objectives with preferences. “Improve audit readiness” is an objective; “must look like a particular product” is a preference and should be disclosed as such. Mandatory requirements should be few, defensible, and connected to risk or performance.

Teams also underestimate exceptions. Demonstrations often show clean invoices, while operations include credits, split allocations, unsupported charges, partial payments, disputed work, and records missing a site identifier. Give vendors realistic examples, subject to confidentiality safeguards, and ask how exceptions are assigned, aged, and escalated. For example, require unresolved invoice exceptions older than 30 days to appear in a management report and older than 60 days to trigger a documented review.

Do not begin implementation immediately after selecting a vendor. The organization should confirm contract authority, security review, data-processing terms, service levels, funding, internal ownership, and a decision calendar before signature. A virtual-utility program can require coordination among facilities, procurement, finance, legal, IT, security, accessibility, and business-unit representatives. Assign one accountable executive and one operational product owner, even if subject-matter experts support the work.

The best decision point depends on urgency. If a current compliance or service failure creates material risk, use a limited corrective process while preserving fair competition and documenting the exception. Otherwise, take 8 to 16 weeks for a typical selection and 4 to 8 months for a complex program. Reconsider pricing, scope, and deadlines if the RFP cannot accommodate reference checks, security review, or a proof of concept. A delayed purchase may cost less than a system that cannot support audit evidence or required workflows.

## Recommended RFP Structure and Closing Decision Rule

A practical RFP can contain an executive summary, current-state profile, objectives, scope, functional and control requirements, integration requirements, implementation plan, pricing schedule, service levels, security materials, acceptance tests, vendor-response forms, and proposed contract terms. Use plain language and number each requirement. Label items as mandatory, scored, or informational. Do not place confidential data in the public response section; use a controlled data-room process where necessary.

Each vendor response should follow the same order and disclose assumptions, exclusions, dependencies, and uncertain commitments. “Assumed” and “included” have very different commercial meanings. The RFP should request a named alternative when a requirement is not met, rather than allowing a vendor to claim partial compliance. Clarification questions should be answered in writing and distributed to all participating vendors so answers do not advantage one bidder.

The final decision should use the pre-agreed matrix, reference findings, exception log, security assessment, contract gaps, and total-cost comparison. Select the response that best satisfies mandatory requirements and provides the strongest evidence for weighted criteria, not necessarily the lowest initial quote. Record why the selected option was chosen and why material alternatives were not. This record protects governance and helps the buyer judge later whether the selected solution delivered its intended results.

Before contracting, resolve any mismatch between marketing language and contractual commitments. Payment milestones should connect to deliverables, and service credits should be meaningful without becoming the customer’s only remedy. Establish measures such as a 99.9% availability target, a support response time of four business hours for production issues, and a 30-day notice period for planned maintenance, or use stricter values where business impact requires them. The final package should be internally approved, operationally rehearsed, and ready for accountable owners.

For a 2026 utility software RFP, the strongest document is neither the longest nor the most feature-heavy. It is the one that lets qualified vendors propose comparably, lets evaluators distinguish evidence from claims, and gives the organization a measurable way to decide whether the system improves vendor and utility operations. That discipline is especially important in public or shared-service settings, where informal influence can create as much risk as an overly rigid specification.

## Quick answers

### How long should a utility software RFP process take?

A typical mid-sized selection takes about 8 to 16 weeks, including requirements, demonstrations, reference checks, security review, and contracting. A complex multi-site or regulated deployment may take 4 to 8 months. Organizations should add time rather than compress security or implementation validation.

### What is the most important RFP requirement?

The most important requirement is a clear connection between the proposed system and the organization’s real workflows, exceptions, and audit obligations. Features should be evaluated through realistic scenarios and measurable acceptance tests. A polished interface cannot compensate for incomplete records or unclear ownership.

### Should an RFP require a fixed price?

Ask for a three-year or five-year total-cost proposal with the same assumptions applied to every vendor. A fixed price is useful for defined scope, but renewals, additional sites, integrations, implementation, support, and exit costs should also be stated. Unclear assumptions are a major commercial risk.

### Is a point solution enough for multi-site utility management?

It can be enough when the organization needs one narrow workflow and has limited sites, users, and entities. Multi-site programs often benefit from shared vendor, invoice, service-request, and reporting records. The deciding issue is whether separate systems create reconciliation and compliance work.

### How should AI use be addressed in an RFP?

Ask vendors to identify AI functions, training-data practices, human-review controls, error handling, and restrictions on sensitive data. Contract terms should state what the provider may retain or use and how affected users can correct an incorrect result. AI should not be assumed to be safe merely because a vendor calls it beneficial.

Canonical: https://vuti.app/knowledge/what_should_teams_include_in_a_utility_software_rfp_in_2026.php
Markdown: https://vuti.app/knowledge/what_should_teams_include_in_a_utility_software_rfp_in_2026.php/index.md