What to include in an RFP for an OMS, with template

What should you include in an RFP for an OMS?

An RFP is a legal document, and an organization's legal department should carefully review it before the software buying team issues the RFP to vendor candidates. A vendor's proposal and its legal language are designed to benefit the vendor, not the customer. An RFP must specify the legal requirements as well as the operational and technical requirements.

Here's what else to include in an RFP for an OMS.

Description of the organization

This section provides background on the software buying team's company and explains why the organization is soliciting proposals for an order management system. This section can include the business reasons for seeking an OMS, an explanation of how the organization currently handles order processing and ways in which the software buying team expects the new OMS will benefit the company.

If the purchasing organization already uses an OMS, this section should explain why the current system needs to be upgraded or replaced. If the current OMS is an on-premises system, this section should also include a brief description of how well it performs and should mention, if applicable, that the organization is open to considering cloud software.

Instructions to bidders

This section provides key information for vendors, such as the due date for submitting proposals, information that the vendor should include in the proposal, penalties for an improper or late submission, details about potential on-site presentations by bidders or a bidders' conference where multiple bidders will attend a discussion session, and any other important requirements.

Proposal format

This section tells bidders how to organize their proposals. The proposal can include the following sections:

Click here to download our
free template for an RFP
for an OMS.

• Cover page and table of contents.
• Intent to respond (may be a separate page).
• Response to confidentiality requirements (may be a separate page).
• Letter of transmittal (may be a separate page).
• Overview of bidding company.
• Proposed software.
• Sample standard vendor contracts and service agreements.
• Financial proposal, which includes the proposed systems and any optional features and services.
• Audited financial statements, such as an annual report or SEC Form 10-K or 10-Q.
• List of references, with an indication of whether the purchasing company can contact them.

The proposal may also include information that the software buying team can use during the evaluation process, such as the bidder's financial position, presence in the market, competitive position and any other relevant decision metrics.

Description of system requirements

This section addresses system elements and capabilities the software buying team is looking for in its new OMS.

Including details is very important here, especially for factors such as interoperability with other systems, networking requirements and scalability. Functions that an organization seeks in its new OMS likely include such tasks as order processing; picking, packing and shipping; and providing data about order processing performance.

The following are key OMS capabilities that every proposed system should include.

Order processing interface for users

The order processing interface usually enables users to carry out the following activities:

• Input new or revised customer data.
• Enter the requested item(s).
• Check for available inventory.
• Orchestrate picking, packing and shipping activities.
• Manage package tracking.
• View data about the overall ordering process, such as time from order completion to package shipment and time from shipping to delivery.

Integration with ERP and other business systems

An OMS's ability to integrate with other systems is very important. Interoperability with ERP software, financial software and other systems will make the ordering process easier to carry out and improve user experience and customer experience.

Networking capabilities

If the new OMS is going to be linked with legacy company systems and resources, it must be compatible with network protocols in use by those systems

Features and capabilities

This part of the RFP includes details about the OMS features and functionality the purchasing company is looking for in its new system, from those the company absolutely requires to those that would be nice to have.

The software buying team should specify the features that the vendor should mention, as most systems have dozens of features and capabilities. The software buying team should also specify whether the company seeks on-premises or cloud software.

The following are some fundamental features of an OMS:

• An interface for the organization's sales and service teams to interact with customers.
• An automated customer interface where the system handles all transactions without a live operator (unless requested by the customer).
• Order management capabilities across multiple sales channels, currencies and geographies.
• Workflow automation, which can help reduce the need for manually carrying out processes like the creation of purchase orders.
• The ability to create shipping labels and select options, such as shipping by truck, airplane or boat.
• Transportation coordination capabilities that enable users to communicate with partners such as shipping companies, the U.S. Postal Service or overnight shipping companies.
• A process for handling returns, such as the ability to create return shipping labels and send a refund to a customer's credit card.
• OMS performance data availability, which can help users determine whether the system is performing optimally and is interfacing with other systems efficiently.
• Forecasting capabilities to alert users about potential problems.
• Maintenance capabilities, including the process for reporting issues, the process for system upgrades and patching, and system warranty details.
• System scalability to accommodate expanded user requirements.

Terms and conditions

This section states various requirements to which each vendor must respond. The following are some terms and conditions that a software buying team can potentially include:

• Disclaimers, such as the fact that the company is not promising to extend a contract because a vendor submitted a proposal.
• The length of time that a proposal is valid.
• The fact that the bidder assumes all costs for preparing the proposal.
• Any specifications about the vendor's ability to modify or withdraw a proposal within a specific time frame.
• The organization's right to accept or reject a proposal.

Timeline for the RFP

This section specifies all relevant dates for vendors during the proposal development and submission process.

These dates can include the date of proposal submission, bidder delivery of questions and user response to questions, bidder demonstrations, bidder conferences and the planned deadline by which the software buying team will have chosen a vendor and awarded the contract.

Vendor company details

In this section, vendors present their qualifications and experience and provide their business credentials.

These credentials can include company name and address, website, DUNS number, tax ID number, company history and current status, number of employees, number of users with the proposed software and any use of subcontractors.

Proposed software

In this section, the bidder presents its official proposal, including explaining why its proposal satisfies the requirements in the RFP.

This section may include a questionnaire that asks for information from the vendor about various aspects of the system.

Free template for an OMS RFP

Here's a template that software buying teams can use to begin creating their RFP.

Paul Kirvan, FBCI, CISA, is an independent consultant and technical writer with more than 35 years of experience in business continuity, disaster recovery, resilience, cybersecurity, GRC, telecom and technical writing.