Modernization is the stated priority
NASPO's 2026 priorities place modernizing the procurement process first, eProcurement/ERP second, and customer service to agency stakeholders third. The organization describes the list as the collective voice of its 54 chief procurement officer members. That does not mean every respondent ranked each item identically. The practical message is that digital tools and agency service belong in the same conversation. Replacing paper, disconnected approvals, or an aging transaction system can improve efficiency, but the priority list is not evidence that any particular implementation method will succeed.
Buyers still need to establish what their own procurement process costs, how it performs, and what its users need before defining the target system. NASPO: 2026 procurement priorities.
Why an unmeasured process creates delivery risk
An unmeasured current process is a foreseeable delivery risk. The solicitation describes desired outcomes; implementation then uncovers approval routes, data quality problems, or exceptions that the requirements assumed away. The result can be change requests, revised schedules, and software that automates an inaccurate picture of the work. Broad IT-project averages offer little help in deciding where this procurement process needs work. The more useful management test is local: can the team demonstrate where time and effort are spent today, and can it explain how the proposed design changes them?
If it cannot, anticipated savings and go-live targets remain hypotheses that require validation.
Build an operational baseline
Our recommendation is to document the process before selecting the platform: count the work the system is meant to improve. This means capturing, in concrete operational terms, what the current procurement process actually costs and does: the average cycle time from requisition to purchase order by transaction type, the labor hours per approval step, the error and rework rate at each stage, the vendor payment lag, and the volume of transactions that fall outside the documented workflow entirely.
Check whether the office has those operational measures alongside its compliance measures—whether procedures were followed and approvals obtained. Where the baseline is missing, fund the measurement work before treating a savings estimate as established. A state can set service obligations and targets without a complete baseline, but it will have a weaker basis for attributing improvement or substantiating promised savings. Establish enough comparable evidence to test the specific benefits in the business case.
AI needs a process it can be evaluated against
AI adds another reason to establish that baseline. Spend analysis, contract risk identification, supplier onboarding, and requisition assistance are potential uses, but availability and quality vary by product. They depend on transaction data, clear policy rules, and a process for reviewing exceptions. A state that cannot measure its current cycle time will struggle to prove that an AI feature improved it. Treat automation benefits as testable claims. Compare results against the existing process, measure erroneous flags and missed issues, and retain human accountability for procurement decisions.
Documented workflows do not make AI automatically safe; they make it possible to evaluate what changed, locate errors, and decide whether the feature should be expanded, adjusted, or disabled.
Agency participation makes adoption more likely
NASPO's third priority—customer service to agency stakeholders—belongs in the design work. Adoption can suffer when a technically functioning system does not match how staff acquire goods and services. One practical way to understand that risk is to watch staff complete real transactions. Involve agency users in mapping current transactions and testing future workflows. Make the operational baseline a shared artifact, with suppliers and finance staff represented where their work is affected. That involvement can reveal duplicate entry, unclear responsibilities, and steps that add little value.
It also gives users a concrete way to challenge assumptions before go-live, when changes are easier to make than after training and migration.
Use discovery to improve the solicitation
For technology firms and professional services providers working in the state procurement space, the measurement gap is both a service opportunity and a competitive differentiator. A larger capital budget does not remove the need for an honest operational assessment of the current process. Vendors can make discovery useful by producing a baseline the state can reuse in its solicitation and acceptance criteria, rather than making the assessment depend on buying a particular platform.
Before the RFP proceeds, the state should know whether its baseline data can support the proposed performance targets. Helping a state answer that question before the formal solicitation opens can improve both requirements and later accountability.
Trace a delayed purchase to the step that caused it
Take an illustrative routine purchase that spends two weeks between request and purchase order. The transaction log alone may suggest that the approval process is slow. A closer review could show that the request waited for a missing funding code, moved quickly through technical review and then returned because a supplier record was incomplete. Those are different problems with different owners.
A new approval screen may help staff see the status without removing any of those delays. Better intake validation may reduce returned requests. Clearer supplier instructions or a finance-data correction may solve another part. The baseline should let the team compare those options before committing to a platform whose business case assumes every delay is caused by paper.
Include the requester, procurement reviewer, finance staff and affected supplier in the walkthrough where appropriate. Ask them to identify work performed outside the official system, including calls, duplicate entry and manual reconciliation. Avoid treating necessary legal or financial review as waste merely because it consumes time. The useful distinction is between an essential control, avoidable rework and a queue that lacks a timely owner.
Keep the comparison honest after implementation
Suppose the new system reports a lower average cycle time. Before attributing that improvement to automation, check whether the transaction mix and measurement boundary remained comparable. Excluding abandoned requests, starting the clock only after intake is complete or moving complex purchases outside the measured system can improve the reported number without improving the full service.
Define the start and end events before the pilot. Report routine and complex transactions separately, retain exceptions and examine the spread as well as the average. A process that improves most routine purchases but leaves a few critical requests waiting needs a more useful explanation than one overall percentage.
The buyer should also distinguish staff hours released from cash savings. Reduced rework may let employees handle more useful work without reducing payroll. That is a legitimate benefit if described accurately. A claim of budget savings needs evidence that spending actually changed or a clearly identified future cost was avoided.
At acceptance, the program owner should be able to explain what improved, which changes contributed and what remains uncertain. A modest pilot may establish that a redesigned intake step is worth expanding without proving that every agency needs the same platform. Conversely, unresolved exceptions may justify additional discovery before broad rollout. The baseline makes those choices visible and helps both the state and the supplier avoid arguing over a success measure invented after the work was delivered.
Measure these before writing the requirements
The baseline does not need to become a research project of its own. A representative sample and a few consistently defined measures can expose the decisions that matter.
- Sample real transactions. Include routine purchases, complex procurements, amendments, emergency buys, and failed or abandoned requests.
- Measure time in the queue separately from work time. Identify where an approval waits days even if it requires only minutes of review.
- Record exception paths. Count missing information, duplicate entry, returned approvals, off-system spreadsheets, and supplier help requests.
- Set acceptance measures before award. Define a comparable baseline, target, data source, accountable owner, and review date for each promised benefit.
- Pilot with agency users and suppliers. Demonstrate the full transaction, including corrections and payments, before expanding to additional agencies.
Sources and further reading
Spartan X's program execution and AI consulting capabilities fit this work at the front of modernization: understanding the process, defining measurable improvements, and connecting technology choices to the results the procurement office needs.
