Free Resource, No Form

Enterprise POS RFP template.
100+ questions to ask vendors.

Every question is on this page. Copy a section straight into your RFP, or take the whole bank as a spreadsheet. Nothing is gated, and you do not have to tell us who you are.

100+Questions
15Sections
0Forms to fill in
CSVOpens in Excel or Sheets
How To Use It

Three things that make an RFP answerable.

Cut it down before you send it

A bank of 100+ questions is for choosing from, not a document to post. Sending all of them produces long, evasive answers. Pick the twenty that would actually change your decision and make those mandatory.

Ask for evidence, not confirmation

Any vendor can answer yes. Require a named reference, a measured figure, a document, or a live demonstration against every claim that matters, and say so in the question.

Score before you read the responses

Agree the weighting with your stakeholders while the field is still open. Deciding what matters after you have read a good-looking response is how organizations talk themselves into the wrong platform.

The Question Bank

100+ questions, in 15 sections.

Use the copy button on any section to take its questions as plain text.

Commercial and licensing

Get the money questions in early. Licensing models differ far more than feature lists do, and the total cost usually turns on the answers here rather than the sticker price.

  1. How is the platform licensed: per store, per terminal, per named user, per transaction, or on revenue?
  2. What is included in the base license, and what is a paid module or add-on?
  3. What is the total cost over five years for our store count, including licenses, implementation, hardware, support and training?
  4. How does pricing change if our store count falls rather than grows?
  5. What are the annual uplift terms, and is there a cap?
  6. What are the contract term, notice period and exit terms?
  7. Are there charges for additional environments (development, test, training)?
  8. What happens commercially if we acquire another retailer mid-term?

Point of sale and checkout

The daily reality of the shop floor. Ask for these to be demonstrated rather than confirmed in writing.

  1. Which tender types are supported natively, and which need a third party?
  2. How are split tenders, partial refunds and exchanges across tenders handled?
  3. What happens to a transaction in progress if the device loses connectivity?
  4. How long does a full offline day of trading survive before storage or reconciliation becomes a problem?
  5. How are discounts, promotions and price overrides controlled and audited at line level?
  6. Can associates complete a sale anywhere in the store, or only at fixed positions?
  7. How many taps does a standard sale take, and how many does a return take?
  8. What does the customer see during the transaction, and is that display configurable?
  9. How are gift cards, store credit and layaway handled across stores and channels?
  10. How is cash reconciled at end of day, and what does a blind count look like?

Inventory and stock accuracy

Ask for measured accuracy in a comparable fleet, not a target. The gap between claimed and achieved is where most omnichannel programs fail.

  1. What item-level inventory accuracy do comparable customers actually achieve, and how is it measured?
  2. How long does a full-store count take, and does the store have to close?
  3. How often can cycle counts run without disrupting trade?
  4. How are receiving, transfers and adjustments handled on the shop floor?
  5. How quickly does a sale, return or transfer reflect in available-to-sell?
  6. How does the system handle serialized inventory, and to what granularity?
  7. What reporting exists for shrink, and how is it attributed?
  8. How is allocation and replenishment decided, and can we override it by store?

Omnichannel and order management

The scenarios that break systems are the ones that cross channels. Push for the failure cases, not the happy path.

  1. Which fulfillment models are supported natively: ship-from-store, click and collect, ship to store, endless aisle?
  2. How is the fulfilling location chosen, and can we configure that logic ourselves?
  3. What happens when a store cannot fulfill a picked order?
  4. Can a customer return an online order to any store, and how is the refund handled?
  5. How are partial shipments and multi-location orders presented to the customer?
  6. What does the associate actually do when an order lands in their store?
  7. How are carrier labels produced, and which carriers are supported?
  8. How is stock protected from overselling during a peak trading event?

Customer data and clienteling

Consent and data residency deserve as much attention here as features. Ask your privacy team to review this section.

  1. How is a customer record created at the till without slowing the queue?
  2. How is marketing consent captured, stored and evidenced per market?
  3. How are duplicate customer records detected and merged?
  4. What customer history is visible to an associate, and can that be restricted by role?
  5. Can customers be registered on their own device rather than the associate's?
  6. How does loyalty work across channels and across markets?
  7. What happens to customer data on a deletion request, and how long does it take?
  8. Can we export the full customer record set if we leave?

RFID and loss prevention

Ask specifically whether RFID is part of the platform or a third-party product sold alongside it. The answer changes the integration and support burden considerably.

  1. Is RFID native to the platform or delivered through a third party or middleware?
  2. Which readers, printers and tags are certified, and who certifies them?
  3. What read accuracy is achieved in a live store, and over what tag population?
  4. How does RFID data reach inventory, and what is the latency?
  5. Can the platform consume vendor-tagged goods, and can tags be printed and encoded at receiving?
  6. What happens to RFID functionality if the store is offline?
  7. What is the cost per tag and per reader at our scale, and who supplies them?

Architecture, hosting and resilience

Involve your architects in writing this section. Ask for a reference architecture diagram as a deliverable, not a description.

  1. Where is the platform hosted, and which regions can our data be pinned to?
  2. Is the platform multi-tenant, and how are tenants isolated?
  3. What is the published uptime commitment, and what is the remedy if it is missed?
  4. What is the disaster recovery plan, and what are the tested RTO and RPO?
  5. What degrades and what keeps working when connectivity is lost at store level?
  6. What is the peak transaction throughput demonstrated in production, by whom?
  7. Can we run in our own cloud tenancy or on premise if we need to?
  8. How is capacity planned for peak trading, and who is accountable if it falls short?
  9. What is the upgrade cadence, and can we defer an upgrade?
  10. How many versions do you support concurrently?

Security, privacy and compliance

Ask for evidence rather than assertions. A vendor that will share a report under NDA is a different proposition from one that will only describe it.

  1. Which certifications and attestations do you hold, and will you share the reports under NDA?
  2. When was your last independent penetration test, and will you share a summary?
  3. Who are your sub-processors, and where is data processed and stored?
  4. How is cardholder data handled, and what is the scope of your PCI responsibility versus ours?
  5. How are fiscal and tax requirements met in each of our markets, and who certifies that?
  6. What is your breach notification commitment and process?
  7. How is data encrypted in transit and at rest, and who holds the keys?
  8. What is the data retention policy, and can we set it ourselves?
  9. How do you handle a customer data subject access request that spans stores and channels?
  10. Will you complete our security questionnaire, and in what timeframe?

Integrations and APIs

Ask to see the documentation before you sign, not after. Whether it is public is itself a useful signal.

  1. Is your API documentation publicly available, and may we see it now?
  2. Is there a sandbox or test environment we can access during evaluation?
  3. Which ERP, WMS, e-commerce and payment platforms are live with customers today?
  4. Are those integrations built and supported by you, by a partner, or by the customer?
  5. What are the published rate limits, payload limits and expected latencies?
  6. How are breaking API changes versioned and communicated, and what notice do we get?
  7. What happens to our integrations during a platform upgrade?
  8. Are webhooks or event streams available, and with what delivery guarantees?
  9. What is the process and cost if we need an integration that does not exist yet?

Identity, access and audit

Shared logins are still common in store systems and are a shrink and audit problem. Ask how the system prevents them rather than whether it supports individual accounts.

  1. How do associates authenticate, and how do you prevent shared credentials in practice?
  2. Does the platform integrate with our identity provider, including SSO and MFA?
  3. How granular are permissions, and can we model our own approval hierarchy?
  4. Is every privileged action attributable to a named individual in the audit trail?
  5. How are leavers, transfers and seasonal staff handled at scale?
  6. Can we export audit logs to our own SIEM?
  7. What access do your own staff have to our production data, and how is that logged?
  8. What options exist where biometric sign-in is not permitted?

Devices and hardware

Hardware choice is where lock-in usually hides. Ask what happens when a device you rely on is discontinued.

  1. Which devices and operating systems are supported, and which are certified?
  2. Are we tied to specific hardware, and can we source it ourselves?
  3. Which peripherals are certified: printers, scanners, cash drawers, payment terminals, RFID readers?
  4. How are devices provisioned, updated and wiped at fleet scale?
  5. What mobile device management does the platform require or assume?
  6. What is the minimum OS version supported, and how quickly do you support new ones?
  7. What happens when a certified device is discontinued by its manufacturer?
  8. What is the expected device refresh cycle, and who bears that cost?

Implementation, migration and cutover

Ask for named references at your store count who went live in the last eighteen months, and speak to them without the vendor present.

  1. Who performs the implementation: your staff, a partner, or ours?
  2. What is a realistic timeline to first store live, and to full rollout at our scale?
  3. Can the platform run alongside our incumbent POS during a phased rollout?
  4. What historical transaction, customer and inventory data migrates, and in what form?
  5. What does rollback look like if a wave fails?
  6. Who is on site at cutover, and for how long?
  7. What is expected of our team, in roles and hours, during implementation?
  8. Which three comparable customers went live most recently, and may we speak to them unaccompanied?
  9. What is the most common cause of delay in your implementations?

Training and change management

Retail turnover means training never finishes. Ask about the second year, not the launch.

  1. How long does it take to train an associate to competence, and how is that measured?
  2. What training materials are provided, and can we adapt them to our own processes?
  3. How is training delivered to new starters after go-live, without vendor involvement?
  4. Is training tracked and certifiable, and can we report on readiness by store?
  5. What does training cost after the initial implementation?
  6. How are seasonal and temporary staff onboarded at peak?

Support, SLAs and roadmap

Ask who answers at 2am on Black Friday, and what their job title is.

  1. What are your support hours, and in which languages and time zones?
  2. What are the response and resolution targets by severity, and what is the remedy if missed?
  3. Who answers a P1 during peak trading, and are they employed by you or a partner?
  4. How do we escalate, and to whom, by name and role?
  5. How is the product roadmap set, and how do customers influence it?
  6. What did you ship in the last twelve months, and what is committed for the next twelve?
  7. How much notice do we get before a feature is deprecated?
  8. What is your customer retention rate, and how many customers left in the last two years?

Exit and data portability

The section most RFPs omit and most regret omitting. Ask it while you still have leverage.

  1. If we leave, what data do we get back, in what format, and how quickly?
  2. Is there a charge for data extraction at exit?
  3. How long do you retain our data after termination, and can we compel deletion?
  4. Can we continue to operate during a transition to another platform?
  5. What assistance do you provide to a successor vendor, and at what cost?
Frequently Asked Questions

Writing a POS RFP, answered.

A POS RFP should cover commercial and licensing terms, point of sale and checkout behavior, inventory accuracy, omnichannel and order management, customer data and consent, RFID if it is relevant to you, architecture and resilience, security and compliance, integrations and APIs, identity and audit, devices and hardware, implementation and migration, training, support and SLAs, and exit and data portability. The last of those is the one most often left out and most often regretted, because it is far harder to negotiate after you have signed.

Fewer than most retailers send. A bank of a hundred or more is useful for choosing from, but posting all of them invites long, hedged answers that are hard to compare. Twenty to forty questions that would genuinely change your decision, each requiring evidence rather than a yes, will tell you more than a hundred that can be answered with a feature matrix.

In practice, four kinds. Requests for measured figures from a comparable live fleet rather than targets. Requests to speak to recent customers of a similar size without the vendor present. Requests for documents, such as an audit report under NDA or public API documentation you can read during the evaluation. And exit questions: what you get back, in what format, how quickly, and at what cost.

Use several, and treat each as a starting point rather than a specification. Any vendor-authored template reflects what that vendor is good at, so cross-reference at least two, add your own operational requirements, and delete anything you would not actually change your decision over. Independent analyst templates are worth reading alongside vendor ones for the same reason.

For a multi-market fleet, expect several months from writing the RFP to signing, and longer again to a first store going live. The stages that most often slip are security and architecture review, because those teams are usually brought in late, and reference calls, because they depend on other retailers' availability. Both are worth starting earlier than feels necessary.

Written by Teamwork Commerce, a POS vendor. We have deliberately included questions we would not win on, because a question bank that only asks what one vendor is good at is no use to you. Judge it on whether it makes your RFP harder to answer.

Put these questions to us.

Bring the section that worries you most to a working session with technical specialists rather than an account executive.

Book a technical review Download the CSV