NDT Software RFP Template: What to Include When Evaluating Vendors

A request for proposal forces vendors to answer questions in writing, on the record, side by side — which is precisely the discipline a software purchase this consequential needs and a verbal sales process rarely provides. A sales demo does the opposite: it lets the vendor control the sequence, skip the workflows that don't flatter the product, and answer follow-up questions verbally in a way that's easy to walk back later if the software doesn't actually do what was implied. For a purchase that will hold years of certification records, calibration history, and client-facing reports, that difference matters. This is a working RFP template — six sections you can copy, adapt, and send to every vendor on your shortlist, including us, so you're comparing the same answers to the same questions instead of comparing polish.

You don't need a procurement department to run this. A structured document with these six sections, sent by email with a two-week response deadline, will get you further than a string of demo calls that all start to blur together by the third vendor.

Before sending it out, decide who on your side actually reads the responses. The mistake most shops make is routing an RFP through whoever handles IT purchasing generally, without input from the people who will use the system daily — the Level II techs filling out reports in the field, the office manager tracking certifications, the ops lead scheduling crews across sites. A technically sound RFP evaluated only for price and general usability will miss the gaps that matter most in this industry: a calibration tracking feature that looks fine in a demo but doesn't actually block sign-off on an expired instrument, or a report template engine that can't reproduce the exact API 653 tank inspection format a specific client contract requires.

Section 1: Company and Method Background

Start by establishing who you're actually buying from. Ask the vendor to state, in writing: how long the company has built software specifically for NDT operations (as distinct from general field-service or asset-management software); which NDT methods the platform natively supports out of the box — UT, RT, MT, PT, VT, ET, TOFD, phased array — versus which would require custom development; and how many active NDT inspection companies currently use the platform in production, with at least one willing to serve as a direct reference. Also ask directly whether the vendor's core product was purpose-built for NDT from the ground up, or is a generalized ERP or field-service tool with NDT-specific fields added on top. Neither answer disqualifies a vendor by itself, but you need to know which one you're evaluating, because the two have very different long-term maintenance profiles.

Section 2: Technical and Functional Requirements

This is the largest section and the one worth the most specificity. At minimum, require the vendor to address, method by method, how the system captures and structures data for each technique your shop runs — not a generic "yes, we support all methods" but the actual field set for each. Require confirmation that mobile data capture works offline in the field (a real requirement on remote pipeline right-of-way or offshore platform work where connectivity is unreliable) and syncs cleanly once connectivity returns. Require the system to generate reports matching established format conventions — ASME Section V Article 4 and 5 UT reporting, API 510/570/653 inspection report conventions, AWS D1.1 weld inspection documentation — either natively or through a configurable template engine your own staff can adjust without a vendor change order. Require certification and calibration tracking to be a first-class, structured feature (individual method-and-level certification expiration per technician, NIST-traceable calibration due dates per serialized instrument) rather than a free-text field or attachment. If your shop does any radiographic work, require explicit confirmation of how digital and film radiography density and IQI sensitivity records are captured and retained, since this is a common gap in generalist platforms.

Go one step further and require the vendor to respond to at least two specific, real scenarios rather than answering only in the abstract. For example: "A UT technician working a scheduled shutdown at a fractionator finds thinning below the retirement thickness on a section governed by API 570 and needs to generate an immediate report flagging the finding for engineering review while still in the field, on a tablet, without connectivity. Walk through exactly how that report gets created, routed, and later reconciled once the technician is back online." Vendors who have actually built for this industry answer concretely. Vendors who haven't tend to answer with generic platform capability statements that don't actually address the scenario.

Section 3: Data, Integration, and Security Requirements

Require the vendor to state explicitly, in the RFP response, who owns the data entered into the system — the client or the vendor — and to confirm this will be stated unambiguously in the contract, not left implied. Require confirmation that the system produces a complete data export, in a non-proprietary format, on request at any point during the contract term, not only at termination. Ask for a description of the data migration process for existing historical records: will old reports be searchable and reportable within the new system, or simply stored as static files? Require a description of available integration paths — a documented API, standard connectors to accounting or ERP systems, and any existing integration with digital twin or enterprise asset management platforms a client might require. On security, require the hosting location, encryption approach (at rest and in transit), backup and disaster recovery policy, and confirmation of the vendor's own cyber liability insurance coverage — increasingly a standard line item on major operator vendor-qualification questionnaires.

Section 4: Implementation, Training, and Support Requirements

Require a week-by-week implementation timeline, stated concretely: who loads historical data, who trains field technicians and office staff, and an honest estimate of how many hours of your own team's time the process will consume before go-live. Require a written support SLA that distinguishes between a production-down issue (a technician in the field unable to submit a report mid-turnaround) and a minor bug, with specific response-time commitments for each — not a general statement that support is "responsive." Ask how ongoing training works for new hires after the initial rollout, since technician turnover is a constant in this industry and a system that requires the vendor's involvement to onboard every new tech doesn't scale.

It's also worth requiring the vendor to describe what happens during their own planned maintenance windows and unplanned outages — specifically, whether field technicians can still capture data offline and sync later, or whether an outage stops fieldwork entirely. A shop running a live turnaround cannot afford a system where a vendor-side outage means no one can submit a report until service is restored. This single question separates platforms genuinely built around field conditions from ones built primarily around an always-connected office use case.

Section 5: Commercial Terms to Request

Ask every vendor on your shortlist to provide a structured, itemized quote reflecting your actual technician count, site count, and method mix — not a single blended number that hides what's driving the cost. Ask specifically what happens to cost as you scale: adding technicians, adding a new method, adding a second site. Ask what's included in the base agreement versus billed as a separate service — implementation, training, data migration, ongoing support, and any custom template work. Most importantly, ask for the contract's exit terms in writing: notice period, data retrieval process and timeline, and any fees associated with leaving. A vendor unwilling to commit exit terms to writing before you've signed is telling you something worth hearing before, not after, you've migrated three years of certification records into their system.

Section 6: References and Proof

Require at least one live reference from a company of comparable size, method mix, and site count to your own, and ask to speak with them directly by phone rather than receiving a written testimonial curated and pre-approved by the vendor's marketing team. Useful reference questions include: how long did implementation actually take versus the original estimate; has the vendor's support SLA held up during a real production issue, such as a technician stranded mid-turnaround; how did the vendor handle the reference's own historical data migration; and, most tellingly, would they choose this vendor again today, knowing everything they know now, or would they shortlist a competitor next time. Also ask the vendor directly how their product has changed in the past 18 months and what's driving the roadmap — a platform actively shaped by real NDT operator feedback behaves very differently over time than one that hasn't meaningfully evolved.

Common Mistakes That Weaken an RFP

The most common failure isn't asking too little — it's asking questions vague enough that every vendor can answer "yes" without differentiating themselves. "Does the system track certifications?" gets a yes from everyone, including a vendor whose "tracking" is a single free-text field. "Does the system support UT reporting?" gets a yes from a generic work-order platform that technically lets you type UT readings into a blank form. Specificity is what makes an RFP useful: ask whether the system blocks report sign-off on an expired certification, not whether it "tracks" certifications; ask whether radiographic density and IQI sensitivity are structured fields, not whether the system "supports RT."

The second common mistake is treating price as the tiebreaker before the technical and compliance sections have actually eliminated any vendors. A lower-cost platform that fails the certification-tracking or data-ownership questions isn't actually cheaper once you account for the audit exposure or the migration cost of switching again in two years. Run the technical scoring first, eliminate anyone who fails the compliance-critical sections outright, and only compare commercial terms among the vendors left standing.

Scoring the Responses

Score each vendor's written response against each of the six sections on a simple weighted scale — for instance, double weight on Sections 2, 3, and 5, since a failure in method coverage, data ownership, or exit terms costs far more over a multi-year term than a rough edge in the training section. Weight compliance-critical sections — data ownership, certification and calibration tracking, and exit terms — more heavily than convenience or interface polish. It's worth involving whoever actually runs day-to-day operations in scoring the technical section, not just IT or purchasing, since they're best positioned to know whether an answer actually solves a real workflow problem or just sounds plausible on paper. A vendor who answers every section clearly, specifically, and without hedging is telling you something about how the relationship will run after the contract is signed — and that predictability is worth more, over a multi-year term, than any single feature demonstrated in a sales call.

If you'd like a second set of eyes on vendor responses before you commit, an ASNT Level III consulting review of the technical sections — specifically the certification tracking, calibration traceability, and reporting compliance answers — is a fast way to catch a gap that a generalist procurement reviewer might not recognize as significant until it becomes one.

Give vendors a realistic response window — two weeks is usually enough for a serious vendor to answer thoroughly without rushing, and it also tells you something: a vendor who responds in two days with generic marketing copy pasted into your document format is showing you how much genuine engineering thought went into the answers, versus one who takes the full window and comes back with specific, scenario-tested responses. Set a hard deadline and hold every vendor to the same one, so you're comparing responses drafted under the same time pressure rather than comparing a rushed answer against a leisurely one.

Finally, keep a written record of every response, not just your own notes on a call. Six months after implementation, when a feature the sales team described verbally doesn't behave the way you expected, the written RFP response is the document you'll want to point back to — both to hold the vendor accountable to what they committed to in writing, and to have an honest record of what you actually evaluated when you made the decision. An RFP process that exists only in scattered email threads and half-remembered calls provides none of that protection. One that exists as a single structured document, answered in writing by every vendor on your shortlist, does.

Atlantis NDT Products & Services

Atlantis NDT pairs field expertise with software: NDT inspection management software — Atlantis ERP, a digital twin platform for asset integrity, and NDT reporting software. Build your team with NDT training & certification (ASNT SNT-TC-1A) and ASNT certification pathways, or bring in ASNT Level III consulting. Affordable, accessible, fully customizable — book a free consultation.