Start with scope, stakeholders and your current data
Most support software RFPs go wrong before the document is written. Teams list features they have seen in demos instead of describing how their support operation works.
Before drafting anything, gather:
- Channel mix: email, chat, phone, social, in-app messaging, community forums. Note rough volume by channel from your current system.
- Team structure: number of agents today and expected in 12 to 24 months, tiers, shifts, outsourced partners, languages supported.
- Integrations: CRM, billing, product database, identity provider, telephony, data warehouse, internal tools agents check during a ticket.
- Pain points: what agents and managers complain about in the current tool. Pull a sample of real tickets that were handled badly.
- Constraints: data residency, industry regulations, accessibility requirements, contract end date of your current vendor.
Then name the evaluation team. A typical group includes a support operations lead (usually the owner), two or three frontline agents, a team lead or QA manager, someone from IT or security, a finance or procurement contact, and whoever owns the CRM. Agree on who has final sign-off and who only advises. Write that down.
Write requirements that actually separate vendors
Every major helpdesk will answer "yes" to "Does the product support ticket routing?" That question tells you nothing. Write requirements as scenarios and ask vendors to explain how, not whether.
Weak requirement:
Supports SLA management.
Stronger requirement:
Enterprise customers must receive a first response within 1 business hour and resolution within 8 business hours, based on the customer's local business calendar. Describe how you would configure this, what happens when a ticket is reassigned or put on hold, and how breaches are reported and alerted.
Organize the RFP into sections:
- Company background and your support context (share your volumes and channels so vendors can price accurately)
- Functional scenarios: routing, SLAs, macros, knowledge base, self-service, automation, AI features, reporting
- Integrations and APIs, including rate limits and webhook support
- Security, privacy and compliance: certifications held, data residency options, SSO, role-based permissions, audit logs
- Implementation: approach, typical timeline, who does the work, data migration from your current tool
- Support and success: support hours, escalation path, named contacts
- Pricing (use your own template, covered below)
Mark each requirement as must-have or nice-to-have. Keep must-haves genuinely mandatory. If a vendor fails one, they are out. A list of 15 to 30 meaningful scenarios is usually more useful than 200 checkbox items, though that is a judgment call, not a rule.
For AI features, ask specifically: what data the model is trained on, whether your data is used to train shared models, how answers are grounded in your knowledge base, and how pricing works (per resolution, per seat, or bundled).
Build the scoring model before responses arrive
Set weights and scoring rules before you open a single response. Otherwise the team tends to reverse-engineer scores to fit whichever demo impressed them most.
An example weighting, to adjust for your priorities:
| Category | Weight |
|---|---|
| Functional fit to scenarios | 35% |
| Agent and admin usability | 20% |
| Integrations and reporting | 15% |
| Security and compliance | 10% |
| Total cost over contract term | 15% |
| Vendor viability and support | 5% |
Use a simple scale, such as 0 to 3:
- 0: does not meet the requirement
- 1: meets it with workarounds or custom development
- 2: meets it with standard configuration
- 3: meets it well and shows it clearly
Have each evaluator score independently, then meet to discuss large gaps. A two-point disagreement on the same requirement usually means someone misunderstood the response or the demo.
Run scripted demos and a hands-on pilot
Shortlist two or three vendors after the written responses. Then take control of the demos.
Send each vendor the same script a week in advance. Include five to eight of your real scenarios, anonymized. For example:
- A customer emails, then follows up on chat an hour later. Show how the agent sees both as one conversation.
- A VIP customer's ticket is about to breach SLA while the assigned agent is offline. Show what happens.
- A manager wants a weekly report of reopened tickets by product area. Build it live.
- An agent needs the customer's plan and last invoice without leaving the ticket. Show the integration.
Give each scenario a time box and score it during the session. Ask the vendor to stay on script and hold general product tours for the end.
After demos, run a pilot with your top one or two choices. A sandbox with a few agents handling copied or low-risk real tickets for one to three weeks is common. Agents will spot friction that managers miss: too many clicks to add an internal note, slow search, confusing macros. Collect agent feedback in a short structured form, not just a thumbs up or down.
Get pricing you can compare side by side
Support software pricing varies a lot: per agent seat, per tier, with add-ons for AI, advanced reporting, extra channels, sandbox environments or higher API limits. If you let vendors present pricing their own way, you will not be able to compare it.
Provide a pricing template that asks for:
- Price per seat by tier, and which features sit in each tier
- Every add-on needed to meet your must-haves, priced separately
- Usage-based charges (AI resolutions, telephony minutes, messaging volume) with the rate and any included allowance
- Implementation, migration and training fees
- Premium support or success fees
- Pricing for three scenarios: current headcount, 25% growth, and a 20% reduction
Calculate total cost of ownership over the full contract term, including internal effort for implementation. Ask whether light users such as managers, QA reviewers or collaborators from other teams need full seats or can use cheaper or free roles. That one detail can move the total meaningfully.
Negotiate contract terms that fit how support teams change
Support headcount rarely stays flat, so the contract needs flexibility. Focus on these terms:
- Seat flexibility: the right to reduce seats at renewal, and ideally a swap or true-down mechanism mid-term. Example wording: "Customer may reduce the number of subscribed seats by up to 15% at each annual anniversary without penalty."
- Price protection: a cap on renewal increases. Example: "Renewal pricing shall not increase by more than 5% over the prior term's per-unit fees." The exact cap is negotiable.
- Price locks for added seats: new seats added mid-term at the same per-unit rate, prorated.
- Usage overages: clear rates for AI or messaging usage above allowances, and alerts before overages accrue.
- Data export and exit: full export of tickets, attachments, users and knowledge base content in a standard format, available for a set period after termination (30 to 90 days is common).
- SLAs for the vendor: uptime commitment, support response times, and service credits for misses.
- Security and privacy: data processing agreement, subprocessor list with notice of changes, breach notification timelines.
- Implementation commitments: named milestones and what happens if the vendor misses them.
Align the start date with your current contract's end date and leave overlap for migration. Running both tools in parallel for a few weeks is normal and should be budgeted.
Let pingpong run it for you
pingpong drafts the RFP, finds and invites vendors, collects proposals through a private portal, scores them with five AI models and flags the gotchas above. It drafts every negotiation message for your approval, then keeps watching the market so you renegotiate before renewal. $100 for the first month, then $799 a month.
Common questions
How long does a customer support software RFP usually take?
A focused process often takes 8 to 12 weeks from requirements to signed contract, though this varies with company size and procurement rules. Security reviews and legal redlines are the most common causes of delay. Start those in parallel with demos rather than after you pick a winner.
How many vendors should we invite?
Inviting four to six vendors to respond is usually enough to get real competition without overwhelming the evaluation team. Narrow to two or three for scripted demos and one or two for a pilot. Keeping a credible second choice through negotiation gives you leverage on price and terms.
Should frontline agents be part of the evaluation?
Yes. Agents spend their whole shift in the tool, and usability problems they catch during a pilot are expensive to fix after rollout. Give them a defined role, such as scoring the usability section and testing specific scenarios, so their input feeds the decision in a structured way.