Services sourcing in most organizations is a complex nightmare. It’s not simple like indirect sourcing where you identify a finished product need, send out an RFQ for a standard product spec, get some quotes, do a landed cost calc using your pre-negotiated or market spot-buy freight rates and current tariffs, and select the lowest cost bid. Easy-peasy. It’s not even straightforward like BoM (Bill of Material) or Program management in a direct sourcing application where you send out a quote package with a set of components, detailed drawings and specs on each component, detailed cost breakdown requests, anticipated production schedules, and compliance and regulatory requirement documents. (And yes, while this is a lot of work to put together even with the best platform, including platforms that can suck in the majority of requirements from the ERP and the PLM, it’s still relatively straightforward for an engineer.)

Services sourcing is complex. While services might have categories for the chart of accounts, and services professionals might have standard roles, and any subsequent request for the same service on the chart of account from someone in the same role with the same experience will be similar, they won’t be the same. Installing a cable line is not just installing a cable line. Is it a home line or business line? Do you have to connect to the poll, a junction box, or a rack mount? Do you have to drill through walls? Are they wood or cement? Implementing an ERP is not implementing an ERP is not implementing an ERP even if it is SAP or Oracle in all instances. What version? What cloud platform does it have to run on / integrate with? Which P2P and back office systems have to be connected? And so on.

On top of the basic project requirements, services projects require a lot of terms and conditions, NDAs, professional certifications and insurance requirements, key performance requirements, confidential information on current state and desired state, evaluation criteria, etc. In a typical organization, a bid package will consist of a huge stack of e-documents, hastily assembled (and riddled with errors due to the haste), zipped up, and sent off to bidders who, hopefully, when struggling to fill out the overly convoluted RFPs on a tight deadline, don’t miss any key requirements before sending it back. (When the organization is in a crunch, which it always is, a lot of this work will often be done by third party consultants who will be less familiar with the requirements than the overworked staff who don’t have time to do it, leading to oversights as well as errors.)

Nvelop was founded to solve these woes, namely

• the time requirement to put together the core of the RFP
• the need to ensure that RFPs contain all the required bid / information fields
• the effort to collect all the corresponding documents
• the need to ensure the terms and conditions satisfy legal
• the need to ensure suppliers see and respond to all mandatory terms and conditions
• the need to communicate with vendors in a secure, trustable, method
• etc.

We’re going to discuss their solution by addressing these points.

The RFP Core

Services RFPs are extensive and time consuming to put together. So Nvelop gets around this by jump-starting the process with LLMs that will create a starting RFP given:

• project type (RFI, RFP Lite, RFP)
• domain (Technology, IT Services, Facility Services, Legal Services, Marketing & Advertising, etc.)
• expected issues (high competition, business criticality, environmental risk, etc.)
• pricing model (fixed price, target price, time & materials, etc.)
• engagement type (staff augmentation, system integration, software implementation, consulting & advisory, etc.)
• business domain (Sales & Marketing, Finance, HR, Supply Chain, etc.)
• Technology [stack] (AWS, Google Cloud, Oracle, etc.)
• Enterprise Software (SAP, Oracle, Salesforce, etc.)
• Business Criticality (1 to 5 scale)
• Background Material (any documents with relevant information that will not be given to bidders)
• brief project description
• meta-data for management and indexing (due dates, owner, team, categorization, etc.)

It will use the LLM that is trained on generic project documents that match the request as well as historical projects from the organization to generate a starting RFP that will break the project requirements down into core processes and sub-processes with supporting requirements for the project type for each sub-process. For example, for an ERP Application Maintenance project, it will define the core processes of:

• application maintenance
• ERP system management
• integration services
• reporting and analytics

and for application maintenance, for example, it will identify the core sub-processes of:

• issue resolution
• incident management
• change management
• performance monitoring
• user support

with a detail description of each sub-process and bidder requirements. For example, for issue resolution, it might break down into

• vendor must allow users to log issues through a portal and issue confirmations and ticket numbers
• vendor must investigate all issues within one business day, regardless of criticality
• vendor must respond to critical issues within one hour with a resolution team and estimated timeframe for resolution
• vendor must maintain a knowledge base updated bi-weekly with common issues and resolutions for self-help
• etc.

Once the initial RFP has been auto-generated, the buying team can

• add internal comments during team discussions and/or collectively prioritize requirements
• manually add, edit, or remove any process, sub-processes, requirement or description
  with status (generated, edited, etc.) tracked
• approve when happy (and the platform can be configured to prevent issuance until all requirements are approved)

All Requirements Accounted For

Nvelop is not a new-age rapidly developed Chat-GPT wrapper parading as a Procurement solution when it really isn’t. It is a new startup founded by consultants who spent 20 years doing services projects while constantly thinking to themselves that there has to be a better way, who came together and defined what the requirements of such a sourcing platform should be, who built a real platform (that walks buyers through a 7-step process), and who only use LLMs for generating content where it makes sense.

The platform has a fairly extensive administration component where, for a project type, you can define:

• the starting bid templates
• core documentation requirements
• mandatory terms & conditions

and the generation logic will ensure that all of these are included in the starting RFP (and associated package) that is generated, either through custom LLM instructions or forced overrides.

It also has a document library where you can store all of your standard documents on company profile, insurance requirements, compliance requirements, general service requirements for personnel on your site, etc. that can be pulled into all relevant projects.

Effort to Collect Corresponding Documentation

Since the platform, as described above,

1. has a document library
2. can, privately, store all related documents relevant in RFP construction on a project basis

It’s very easy to automatically include all of the relevant documents in an RFP, as the majority will already be in the system, and the rest can simply be uploaded and the majority of relevant content auto-extracted by the LLM during the initial generation process.

Terms and Conditions Satisfy Legal

Not only can you include a standard clause library, in the administration section, but you can configure the application to use pre-approved legal clauses verbatim in requirements and draft agreement generation, and the LLM will only be used to generate the parts of the RFQ and draft agreement for which there is not a verbatim clause. In addition, if a clause needs to be adjusted for different geographies, categories, etc., you are able to configure the application to force the LLM to generate its response based on a library clause. In other words, if you already have something acceptable, you can be sure it makes it into the RFQ or draft agreement vs. just rolling the bones.

Forced Supplier Response on Mandatory Ts and Cs

RFIs and RFP packages can be designed to force a supplier to respond to each mandatory and critical requirement, where they can simply select a Yes/No or Yes/Partal/No response with additional commentary, if required. This way a supplier can never say “they didn’t know” something was a requirement in the final stages of a negotiation as they will have seen and responded to it during the initial bid and requirements traceability is a core part of the solution platform.

Secure Communication

Since the RFP process is now going through a platform, where all documents can be securely downloaded and uploaded, all communications securely maintained in their own, auditable, stream, and all required confidential documentation can be accessed at any time once the NDAs have been accepted, the platform solves the security issue that buyers and vendors have with sensitive documents and bids being sent back and forth through email or common FTP portals.

Solution Summary

As we hinted above, the solution will walk a buying team through a seven-step process that consists of:

1. Planning – enter all the data you have and instruct it to generate a starting RFQ
2. Requirements – edit and finalize the requirements listing
3. RFQ – finalize the RFQ (by approving or editing), which will consist of
   • overview information (introduction, your client info, submission and evaluation process, technical landscape, services overview requirements, services timeline, and other relevant information sections)
   • Questions – the requirements you worked on last phase, which can be extended with other questions about the vendor not core to the services requirements
   • Pricing – where the vendor will submit the bid sheets in the appropriate format that is automatically identified based on procurement type and category (including fixed price bids, rate cards, etc.)
   • Evaluation Criteria – where you define the criteria (and weighting)
   • Attachments – automatically pulled in
4. Tendering – where you can see the RFP Preview (as the vendors will see it), select the vendors, and handle the Q&A; and where you can resend if you have to make an update or do a subsequent round
5. Responses – which captures the vendor responses
6. Evaluation – where you evaluate the responses once the RFQ is closed, and can compare them side-by-side at a high level, drill down into the details, and have the system generate overall scores based on the evaluation criteria (and weighting) you define
7. Deal Room – where you kick off a negotiation process with one or more vendors, assisted by an automatically generated assessment of deviations from specifications or requirements that you will need to address (which will be based not just on clicked boxes but comments, likely intention, degree of deviation, summary of the deviation, assessed negotiation complexity, and likely relative importance)

Moreover, a supplier can easily access, and respond to the RFQ, through the vendor portal that allows them to quickly access the relevant sections, check the boxes, provide their responses, and upload documents. They can also engage in Q&A, and see the status of each project they have been invited to. The Q&A capability includes a LLM-powered chatbot that will search all of the available documentation and provide answers to questions already answered, including pointers to where to find that information in the RFQ package, and that will, when an answer is not found, direct the user to directly message the buyer for the answer.

Why SI is Covering and Recommending Nvelop for Shortlist Configuration

Those who follow SI will know that the doctor despises the rampant proliferation of untested Gen-AI and the random application of Gen-AI to every problem, even a problem so obviously far beyond what Gen-AI was suited for that even a complete idiot would abandon the tech once they say how bad it worked, so why does the doctor recommend this Gem-AI powered platform?

1. it’s not Gen-AI / LLM driven
   the core is a solid workflow app that follows a process that the founders, each of whom have over two decades of services sourcing support, know works
2. LLMs are being used for what they are good for
   massive document store summarization and document generation off of standard requirements and similar projects
3. the LLM can be fine tuned
   and you can direct it to (re)generate an entire package, single document, single section, single process, or single line-level requirement description with additional instructions
4. everything can be overwritten or manually generated in the first place
   Gen-AI was never meant to be the solution, but a starting point that can get you 90% to 95% of the way there when you don’t have an out-of-the-box solution, so it is designed to generate content where it can get “close enough” and where it’s easier to manually edit the generated output than to even generate a starting document from scratch through cut-and-paste
5. every single line MUST be manually approved
   and while you can click that “approve” button without reading the associated content, if something is issued wrong, then everyone knows who didn’t do their job and who is ultimately responsible

Moreover, it will get you through a complex sourcing project mostly correct and mostly complete in a matter of weeks, with little to know external (consulting) support required, even if you’ve never done that particular complex sourcing project before! And while no solution is perfect, we’d hazard a guess to say even a neophyte would do a better job with this platform than a grizzled veteran who had to do everything manually under a severe time crunch. (While the grizzled veteran likely wouldn’t make any mistakes on anything they touched, they would be likely to miss something important in the virtual stacks of paperwork with more pages than a copy of “War and Peace” [Simon & Schuster edition] given the time crunch they are always under.)

Nvelop might be new, but it’s solid, which is what you get when you realize it is a solution built by veteran complex services sourcing professionals specifically to support the processes that complex services sourcing professionals use. So if you are in an industry with a lot of services sourcing requirements, and your current sourcing solution (designed for indirect and direct) is letting you down (and it is), then we recommend you at least give this solution a look. The responsible use of AI impressed the doctor, so we would fathom a guess that it should impress you too.