Method and System of Obtaining a Bid For Services

A method and system of obtaining a bid from a provider of services, involving creating a client request for proposal (RFP) document, storing client RFP document in a data store, inviting a bidding service provider to respond a stored client RFP document, allowing an invited bidding service provider to access the stored client RFP document, allowing the bidding service provider to respond to the stored client RFP document, obtaining all completed responses and all rate elements from bidding service providers, generating a comparative financial analysis showing a sorted list of responses, generating a weighted report, the generated weighted report comprising a display of bids having a best compliance with client RFP document in top down order based on the comparative financial analysis, and providing the generated weighted report to the client.

BACKGROUND

Coordinating a request for proposal (“RFP”) to provide a service to a consumer of services, and coordinating responses to the RFP from a number of service providers, can be complicated and time consuming. Typically, the RFP process involves obtaining a response from each bidding service provider, such as but not limited to a telecommunications carrier, as to if and/or how they will comply with the requirements outlined in the RFP document. It can be helpful to have these responses generated as part of an auction or reverse auction process to arrive at the most competitive bid.

Problems arise when a request for services attempts to solicit bids but the requesting party cannot adequately compare responses because service providers either cannot provide all requested services and/or include “hidden” charges such as non-mandated surcharges in their responses. It also sometimes occurs that bids are accepted which do not reflect true responses for all intended services.

DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS

In the system described herein, requests for bids and responses to such requests are typically displayed dynamically and the system allows updating of bids and of bids in real-time. The system and its computer-implemented methods are not simply the generalized use of a computer as a tool to conduct a known or obvious process, but, instead are improvements to the capability of a request for proposal system as a whole that allow a requesting party to compare responses where service providers provide all requested services where such comparisons include analyses of “hidden” charges such as non-mandated surcharges in their responses. This allows a requesting party to view and accept bids which reflect true responses for all intended services.

Referring now toFIG. 1, system1for processing a bid from a provider of services comprises web portal10; computer20operatively in communication with web portal10; data store30operatively in communication with computer20; database40disposed on data store30; database management software50operatively resident in computer20, the database management software operative to manage database40; and bid proposal software60operatively resident in computer20, operatively accessible to user2and service provider3via web portal10, and operatively in communication with database management software50.

Web portal10is operatively, and in certain embodiments securely, accessible via a data network such as the Internet, typically via network interface22which is further accessible to computer20. In a first embodiment, web portal10further comprises an ASP.NET component; a C# code behind component operatively in communication with the ASP.NET component; and an SQL database interface component, such as a Microsoft SQL Server database interface component, operatively in communication with the ASP.NET component or the C# code behind component, as these terms are familiar to those of ordinary skill in the programming arts. In a preferred embodiment, a predetermined number of data objects are also provided which comprise an AJAX component configured to communicate between client software processes and server software processes and a dual application programming interface (API) configured to be called from either a client or a server software process.

Database40typically comprises service provider table42comprising service provider data associated with service provider3; request for proposal table44comprising request for proposal data associated with client2; bid table46comprising service provider bid data associated with service provider3, client2, and a specific RFP, e.g. client RFP document100(FIG. 2); and request for proposal table48comprising RFP data such as may be reflected in client RFP document100. These data are typically associated with, and/or obtained via, client RFP document100(FIG. 2).

Referring additionally now toFIG. 2, in typical embodiments client RFP document100comprises service description section101, describing one or more services, such as but not limited to telecommunication (“telecom”) related services, that client2wishes to obtain from service provider3; a set of specific requirements102(e.g.,FIG. 10) associated with each service; textual description103of the service (e.g.,FIG. 10); a predetermined set of individual rate elements104(not shown in the figures) of the service; and a predetermined set of associated current costs105(not shown in the figures) associated with the service. In further embodiments, client RFP document100may comprise a user or programmatically customizable client logo cover page106; one or more document sections107(e.g.,FIGS. 2 and 10) linked to client RFP document100; one or more document subsections108(e.g.,FIGS. 2 and 10) associated with document section106; timeline109, comprising an outline of a timeframe of all RFP items within a process for responding to client RFP document100, where timeline109is linked to document section106; and an image comprising a link to either document section106or document subsection107. The image, if present, may be embedded during the generation of client RFP document100in a printable or exportable form of client RFP document100.

Referring back toFIG. 1, bid proposal software60typically comprises template software62(not shown in the figures), bid software64(not shown in the figures), analysis software66(not shown in the figures), and response software68(not shown in the figures), each tailored to provide templates, bidding features, analysis features, and response features respectively, as further described below.

Template software62is typically configured to present a request for proposal form to client2, obtain a desired set of services selected by client2using a request for proposal form such as illustrated inFIG. 8, and uniquely associate the selected desired set of services with client2in a unique record of request for proposal table44.

Bid software64is typically configured to present a bid form, such as illustrated inFIG. 11, to service provider3, allow service provider3to bid on providing the desired set of services selected by client2using the bid form, and associate the bid with the unique record in request for proposal table44.

Analysis software66is typically configured to compare bid data from one service provider3against bid data from each other service provider3for a specific, selected request for proposal record in request for proposal table44and generate a ranking for each such service provider3with respect to the specific request for proposal data associated with client2.

Response software68is typically configured to present a rank ordered set of each such service provider3without allowing any service provider3to see any actual bid data from another service provider3while, at the same time, allowing client2to see actual bid data from each such service provider3.

In the operation of exemplary embodiments, a bid from a provider of services, i.e. service provider3(FIG. 1), may be obtained by creating client RFP document100(FIG. 2) which is as described above. This can be via web portal10(FIG. 1) or any similar means, such as but not limited to paper forms or computer scannable forms or the like or a combination thereof. Such a bid will be for supplying one or more of the requirements and requests reflected in client RFP document100(FIG. 2), i.e. a conforming bid.

Responses from service providers3to requirements and requests reflected in client RFP document100(FIG. 2) are usually accomplished using web portal10(FIG. 1) by having each invited service provider3(FIG. 1) supply an answer to each required portion in client RFP document100when prompted to do so by a form on web portal10. In some embodiments, service provider3may be allowed to import a client RFP document service provider rate response using a predefined import template corresponding to a specific service type. Additionally, an Administrative User (described below) may import a current cost for a specific service type by using a predefined rate import template corresponding to a specific service type.

Web portal10(FIG. 1) is usually configured to selectively allow access to client RFP document100(FIG. 2) to clients2(FIG. 1), who created a client RFP document100, and service providers3(FIG. 1) who have been granted such access.

By way of example and not limitation, each user of web portal10is typically categorized such as an Administrative User, a Client User for client2(FIG. 1), a Service Provider User for service providers3(FIG. 1), or the like. Web portal10(FIG. 1) further typically comprises a set of user interface displays, generally described below, which implement and provide a user interface configured to provide a plurality of options to each user of web portal10. Typically, the user interface selectively guides a user of web portal10in the steps needed to complete their required input into the RFP process. By way of further example and not limitation, web portal10may comprise or otherwise make various forms available such as browser-enabled or other Internet available forms, as illustrated inFIGS. 3-14. As illustrated inFIGS. 3-14, either an Administrative User or Client User with appropriate permissions can setup a Client User account (FIG. 3) and assign one or more roles/permissions to such a user (FIG. 4). Client Users can create and/or edit client RFP documents100(FIG. 2) and approve such client RFP documents100via one or more forms (FIGS. 5 and 6). Once submitted, Service Provider Users may be invited to view and respond to client RFP documents100via a form (FIG. 7). Client User and others may see a list of those Service Provider Users who have been invited, along with status information on their bidding, if any (FIG. 8). Client Users and/or Service Provider Users may retrieve (FIG. 9) client RFP documents100and modify various aspects of their response (e.g.,FIG. 10). As illustrated inFIG. 10, Client Users can add descriptive or disclaiming qualifiers to portions of client RFP documents100(FIG. 11). Service Provider Users can use one or more forms (e.g.,FIG. 12) to qualify and/or create a response to client RFP documents100. Once bidding ceases, as described below, a weighted report (FIG. 13) may be generated and presented to client2such as on demand via web portal10.

Client RFP document100(FIG. 2) may further comprise a client RFP document profile and a current spend by service types outline. In these embodiments, client RFP document100creation may further comprise adding a service type that is within a scope of client RFP document100to a client RFP document profile; creating a link between client RFP document100and a current spend by service types outline in client RFP document100; and creating a link to client RFP document100and an entry placed on all service provider profiles that are invited to bid on that service type for a specific RFP embodied within client RFP document100. For client RFP documents100that include document sections107(FIG. 2) and document subsections108(FIG. 2), these document sections107and document subsections108may be numbered and categorized each document section107. For a plurality of invited service providers3(FIG. 1), a response from a first invited service provider3may be compared to each other response from each other invited service provider3using the numbered and categorized document section107and document subsection108for a document section107or document subsection108which requires a response.

Typically, each client2(FIG. 1) has an assigned account which comprises a username, password, and a profile. (See, e.g.,FIGS. 3 and 4) Client2may be allowed access to a specific client profile and client RFP document100(FIG. 2) associated with the specific client profile.

Each client2typically has the option to use their own document, which is in a predetermined format such as a Microsoft® Word® format, or use a customer tailored document that caters to their specific needs. Once the content of RFP document100(FIG. 2) is processed and analyzed as described herein, a copy of RFP document100(FIG. 2), in Word® format, is imported into system1. The process of loading a document into system1is a technological breakthrough in document handling.

Once loaded, system1parses RFP document100(FIG. 2), extracts various information such a section number, section name, subsection number, and subsection name, and inserts the extracted information into a predetermined data structure such as for ease of maintenance and segregating individual section/subsection responses from each service provider3. It is understood that there may be none or a plurality of each of these various information members.

An option may be provided to require a written response and/or compliance to the context of a section/subsection from service provider3to whom access will be granted. Additionally, an option may exist to flag a specific item of the extracted information to require a positive compliance response to that specific item. As used herein, items requiring a positive compliance response are referred to as “deal-breakers.” The absence of a positive compliance response to a deal-breaker item may automatically disqualify service provider3from further consideration.

Upon document import, a response placeholder corresponding to a response from service provider3is typically created for each section/subsection in the document to which service provider3has access. If the section/subsection requires an answer or contains a compliance question, each response is captured and stored.

With each open request, system1analyzes the responses provided by each such service provider3and provides completion statistics to client2. These completion statistics can allow a real-time view into the request process. Without system1, client2would not be able to view the completion in real-time and would need to wait for service provider3to submit a completed response document. System1also permits real-time comparison of responses from all service providers3to each section/subsection. This permits client2to compare responses from service providers3in real-time on a response item level. This eliminates a manual collation of all provider responses.

Typically, service providers3, upon login to system1, are required to respond to deal-breaker questions first. Only after they have responded positively to the deal-breaker questions are they permitted to continue. This process gives each such service provider3an immediate alert that they are no longer considered and gives them the option to change their response without any intervention from client2and/or system1. Additionally, service provider3receives instant feedback on their response and eliminates delay in requesting an updated response after the close of the request.

The capturing of responses from service providers3is done for each section/subsection on a section/subsection by section/subsection basis. Service provider3sees information related to a section/subsection and any written response and compliance requirements for that section/subsection. This permits service provider3to have the appropriate personnel in appropriate departments respond to sections/subsections that apply to the scope of their department. This expedites the response time from service providers3by permitting input from multiple departments substantially simultaneously.

Similar to a document section, a document subsection can have the same response requirements. They are also typically created during importing of RFP document100(FIG. 2). For example, document section1may have four subsections (1.1,1.2,1.3and1.4) which would result in the creation of four document subsections for the parent document section. All responses for document subsections are separate and distinct from the parent. They can also include compliance questions, including deal-breakers. Each response is typically logged separately from service provider3. If any deal-breaker compliance responses are present in either the document section or subsection, all must be responded to with a positive response before service provider3can continue on to other questions. Any negative response to a deal-breaker question typically automatically disqualifies service provider3and removes further access to the request document and rates for that service provider3with respect to responses to RFP document100.

Client2typically provides system1with a list of service items that are included in the request. These service items are typically detailed by service type. In addition, client2typically indicates which term length is to be applied to the request. Client2has the option of applying multiple term length requests simultaneously. The services items may be provided by client2in Excel® format, or client2can choose to have system1to conduct data mining from invoices of client2. Once the Excel® file is built of the available service items, they are imported into system1.

Referring additionally toFIG. 14, the importing of service items into system1is a further technological breakthrough. To start the process of importing inventory for a given service, inventory template200is exported from system1, typically to service template201in spreadsheet file210which is formatted to comprise a predetermined set of columns for the service items client2wishes to import. All service templates201generally contain tabs for each segment of the desired service or services, along with explicit instructions of how to populate inventory template200to create service template201. Once service template201is exported, service items to be imported are populated and then spreadsheet file201is uploaded to system1. System1will then process spreadsheet file201, generally comprising reading it, validating the items for completeness and accuracy, and locating each such item to be updated in database40. If any errors are found, system1creates a report, typically an error spreadsheet, indicating which content in spreadsheet file210resulted in error and the reason for the error.

Without importing/exporting within system1, all document responses and inventory service items would need to be done manually through data entry. Thus, system1's data validation that occurs for each document response and inventory service item is unique to all aspects of the request/response of a sourcing engagement. Segmenting document sections and creating placeholders for the computation of percentage of completion as well as the ability to report on no responses is also unique.

System1can automatically create placeholders for provider responses for each service item and term length combination, making it easy to collect and analyze each term length separately. Client2may request rates for multiple term lengths in the same request. Terms lengths are typically for 12, 24 and/or 36 months.

All service inventory items represent the current services client2currently has installed. As each new service offer arises, system1may be updated to handle the service template for new services. Sample data structures for Long Distance service:

Additionally, service provider3(FIG. 1) may be allowed access to a specific service provider profile and to only those client RFP documents100for which they have an active invitation. The service provider active invitation usually comprises a set of permissions which selectively allow or disallow access to specific sections of client RFP document100to which a specific service provider3may respond as well as a definition of which service types on which they may place a bid.

The granting and denying of provider access to specific document sections and inventory service elements is unique to system1and the sourcing industry. When service provider3(FIG. 1) accesses system1, they are presented with a list of deal-breaker questions initially. Service provider3must respond with a positive compliance to these questions first. If they do not respond positively they are typically disqualified immediately and their access to the request is automatically revoked. If service provider3is permitted to continue, the remaining responses to the request are opened for access, providing access has been granted. They are also permitted to export the inventory service items in which they are permitted to respond.

Without this feature, client2would need to wait for the provider's response, normally towards the closing date of the request, only to discover service provider3will not comply with the initial requirements of the response. This wastes time and money for client2, system1and service provider3.

Once obtained, client RFP document100(FIG. 2) may be stored in data store30(FIG. 1), which can be accessed by using web portal10(FIG. 1). Receipt and storage of client RFP document100may then trigger, such as by bid software60(FIG. 1), inviting one or more service providers3(FIG. 1) to be invited to respond to a stored client RFP document100by submitting a bid. To do so, each invited bidding service provider3may be allowed to access a stored client RFP document100, typically during all of the duration of RFP timeline109(FIG. 2) embodied within client RFP document100, and further allowed to respond to a stored client RFP document100by submitting an indication of the specific requirements with which service provider3will comply. Typically, for each specific requirement with which service provider3will comply, service provide3supplies an indication of how they will comply with each specific requirement; a textual response, if needed, such as to further clarify their response; and the actual bid for services from service provide3which represents the financial aspect of services they wish to provide to client2.

Upon completion of the deal-breaker compliance response requirements, service provider3can then access the inventory service items to which they have been granted access. Service providers3first typically export service item template201(FIG. 14) for a given service. This will list out the common data for a given service item response and typically include client name, document name, location, reference number, and service specific response columns. Service provider3then can enter their response into exported spreadsheet210(FIG. 14). Upon completion of all responses in spreadsheet210, service provider3can then import spreadsheet210back into system1. System1will verify the information provided and stow all responses into appropriate placeholders which have been created. Each placeholder, whether they are section, compliance, or inventory service item responses, counts as a total number of responses required. For example, service provider3may need to respond to 10 sections, 20 sub-sections, and 400 inventory service items, for a total of 450 responses. The completion statistics is computed by setting the percentage of completion to (total provided/total required). Client2can view completion statistics real time. Service provider3typically then receives an email with their completion statistics starting seven days prior to the close of a request. The email is sent daily until close or until service provider3has completed 100% of the response requirements.

This feature manages the progress of service provider3and alerts both client2and service provider3of the progress of such service providers3. This actually tends to increase response time from service provider3since service provider3does not want to look bad in the eyes of client2.

In order to provide client2a true cost from a given provider, the option to collect non-mandated surcharges from service provider3is typically set on the request document, e.g. via a Boolean flag or semaphore or the like. Service provider3must then import their non-mandated surcharges (NMS) for the surcharges that are configured on the inventory service item. The provider's NMS charges are represented as a percentage and applied to specific columns in the response from service provider3to compute NMS charges by provider/service. This feature prevents hidden costs from service provider3if that service provider is selected. It also gives power to client2to have service provider3remove undisclosed additional costs during contract negotiation as well as from billing after services are installed.

The computation of non-mandated surcharges typically uses dynamic structure query language (SQL) in the database code and, accordingly table and column names are typically included for such use. The dynamic SQL code builds the query to execute to compute NMS based on the configuration of the tables and columns to which the NMS charge applies.

NMS charges are also typically included in the financial analysis report for a true net-net cost assessment. This feature provides a true net-net amount on the financial analysis report for client2to make a more informed decision on which service provider3to award a contact at the end of the final round on a specific request. For example, not all service providers3charge the same tax amount nor do they charge the same NMS charges. This feature gives a clear picture to client2and holds service provider3accountable for not disclosing hidden charges and taxes.

At a first predetermined time, bid software60(FIG. 1) obtains all completed responses and all rate elements from bidding service provider3(FIG. 1). At a second predetermined time, bid software60generates a comparative financial analysis showing a sorted list of responses. This analysis, typically by analysis software66(not shown in the figures), indicates savings over current costs105on a service provider by service provider basis and indicates savings over current costs105on a service type by service type basis, as illustrated inFIG. 13.

Generating the comparative financial analysis comprises generating a true monthly cost comparison for each service provider3(FIG. 1) that bids on a specific service type. In a first preferred embodiment for telecommunications services, a sum of the product of rate units/quantities multiplied by the rate per unit/quantity for all rate elements per service type is created for current costs and corresponding rate responses from each service provider3bidding on that service type. For telecommunication service providers, migration credits are subtracted and internal migration costs are added together. The internal migration costs are extrapolated out over a term of the commitment.

Client RFP document100(FIG. 2), as originally created, may be coupled with responses from service provider3(FIG. 1) to client RFP document100linked to each document section107(FIG. 2) and document subsection108(FIG. 2) that required a response and to which service provider3was invited to respond.

The financial analysis may further comprise comparing the total to be spent to the total bid from service provider3(FIG. 1) for each service type and service provider after all service provider responses have been received.##

At a third predetermined time, bid software60(FIG. 1), e.g. response software68(not shown in the figures) and/or analysis software66(not shown in the figures), may generate a weighted report which comprises a display of bids having a best compliance with client RFP document100(FIG. 1) such as in a top down order based on the comparative financial analysis. This generated weighted report (FIG. 12) may then be presented to client2(FIG. 1) such as on demand via web portal10(FIG. 1).

In certain embodiments, an auction process may take place including selectively enabling or disabling a reverse auction by using an option on a client RFP document level during the duration of RFP timeline109(FIG. 2). The RFP timeline109may be embodied within client RFP document100(FIG. 2). For enabled reverse auctions, automatic updates of rankings of bids from an invited service provider3(FIG. 1) may be displayed, such as when service provider3submits a bid, including a display of rankings of each bid from each invited service provider3against each bid from each other invited service provider3and of each bid from each invited service provider3by their current rank in the bidding process.

An invited service provider3(FIG. 1) may further be allowed to run a document response report and/or a rate response report in real time on demand during the duration of an RFP timeline embodied within client RFP document100(FIG. 2). Client2(FIG. 1) may also be allowed to run a document response report and/or a rate response report in real time on demand at any time as their access permits.

In an alternative method, obtaining a bid from service provider3(FIG. 1) for providing a set of desired services to client2(FIG. 1) comprises obtaining a set of desired services from client2, such as third-party telecom services; providing a first browser-based form that displays the set of desired services to a predetermined number of service providers3such as third-party telecom service providers; and obtaining a bid from a plurality of these service providers3to provide one or more of the set of desired services.

Once obtained, the bids obtained from each of the service providers3(FIG. 1) may be analyzed to generate a ranking for each such obtained set of bids, the ranking based on a predetermined set of ranking criteria. The analysis is typically performed by analysis software68(not shown in the figures) resident in computer20(FIG. 1) operatively in communication with the first browser-based form and may be triggered automatically by entry of one of the bids from one of service providers3.

A first ranked listing display of the ranked bids may be generated and made available via a second browser-based form viewable by service providers3(FIG. 1), where the second browser-based form displays the ranking but not the actual bid data from service providers3. A second ranked listing display may also be generated based on a predetermined set of ranking criteria and the actual bid data from the service providers3. Client2(FIG. 1) may be allowed to view the second ranked listing display such as via a third browser-based form viewable by client2, where the third browser-based form displays the ranking and the actual bid data from the providers of services.

In third embodiment, a bid from service provider3(FIG. 1) to provide a set of services to client2(FIG. 1) comprises obtaining login information from client2, who is a consumer of services, and validating the login information. Upon validation, a predetermined portion of a browser-based form, viewable by client2, is populated with a set of predefined service templates associated with client, e.g. by bid software60(FIG. 1). A set of allowable service types for client is displayed, such as via a first browser-based form and a set of desired service types obtained from client from the set of allowable service types. This set of desired service types may be associated with a request for services and the request for services associated with client2such as via client RFP document100(FIG. 2) which is stored in data store30(FIG. 1).

A predetermined set of service providers3(FIG. 1) may then be invited to bid on providing those service providers3with access to the set of desired service types, e.g. via access to client RFP document100(FIG. 2), and allowing each of the invited service providers3to submit a bid to provide the desired service types associated with the request. This provision may be by using a second browser-based form.

Upon receipt of each such bid, analysis software68(not shown in the figures) may be used to analyze the obtained set of bids and generate a ranking for each such obtained set of bids, where the ranking is based on a predetermined set of ranking criteria. The analysis may be performed either on demand, periodically, automatically, by being triggered by receipt of a change in a bid from service provider3(FIG. 1), or the like, or a combination thereof

A ranked listing display of the ranked bids may be made available to client2(FIG. 1) via, e.g., a fourth browser-based form viewable by client2and invited service providers3(FIG. 1). Ranking is typically based on the total rates.

Invited service providers3(FIG. 1) may only see the ranking but not the actual bid data from the other service providers3. However, client2(FIG. 1) may be allowed to view the ranking, such as via another browser-based form only viewable by client2, based on a predetermined set of ranking criteria, and see the actual bid data from the service providers3, as illustrated inFIG. 13. Client2may also be allowed to filter the bids by selecting one of the desired service types and, upon selection of the desired service type, populating a portion of the browser-based form with preview rate responses.

Where template200(FIG. 14) comprises a request for proposal, template200may be populated with information for a plurality of service types and, upon selection of template200by client2(FIG. 1), service providers3(FIG. 1) for each requested service type may be listed or otherwise displayed.

Financial analysis reports, which are exclusive to system1, may be generated and are very specific to how system1applies responses from service providers3, NMS charges, and taxes. The algorithms used produce true net-net comparisons. All reports are generally dynamic in nature, providing comparison columns for each service provider3responding to given request. For example, one request may have three service providers3responding, and another request may have ten service providers3responding. The report will automatically adjust the columns on the report to accommodate the number of responding service providers3. In addition to the financial analysis report by inventory service, system1may generate an all services report which blends all individual service reports into a combined financial analysis report for an overall view into the request result.

In any of these methods, service providers3may be allowed to adjust their bids during a predetermined period of time, e.g. an RFP timeline109(FIG. 2) embodied within client RFP document100(FIG. 2). Further, client2(FIG. 1) may be allowed to select one of the ranked bids, either at the conclusion of the process or at any time and, if client2does so, the service provider3that submitted that selected bid may be notified of the selection. In some embodiments, an advance agreement may be obtained from service provider3(FIG. 1), stating that making the bid constitutes a legally binding offer from service provider3and a corresponding advance agreement obtained from client2that selecting the bid by client2constitutes a legally binding acceptance of that offer. Optionally, service providers3who are not selected may be notified that they were not selected such as by electronic mail.

The foregoing disclosure and description of the inventions are illustrative and explanatory. Various changes in the size, shape, and materials, as well as in the details of the illustrative construction and/or an illustrative method may be made without departing from the spirit of the invention.