A prerequisite for participating in public tendering processes is finding the tender, reviewing the details, and forwarding it to the internal process if necessary. Employees in the tender management department of one of our client companies manually checked three different procurement portals at regular intervals and transferred the relevant information into their own system. Our PoC aimed to automate precisely this recurring path from portal to usable data, so that employees can focus on the technical assessment of the tender.
The technology behind our tender agent
To develop the agent prototype, we used Copilot Studio‘s computer-use functionality. This allows us to capture screen content and operate websites with a virtual mouse and keyboard. This is the method of choice when information is provided via a flexible interface, but no suitable API is available for the planned retrieval. Our agent therefore works like a human using visible web pages: it opens the designated portals, uses their search forms, and collects the desired information.
During setup, the agent must be given instructions on which portals to visit and what criteria to search for. For portals requiring login credentials, appropriate access details must be available. Copilot Studio offers a good solution for this: access data for websites can be securely stored in “Stored Credentials.”
After searching, the agent returns selected information in a defined JSON format. This allows matches to be structured into Dataverse and made available in a CRM for further processing. The datasets created as leads or sales opportunities, and the tasks that arise from them, must be determined according to downstream processes.
A practical example of the agent's flexibility: the case of the 50 km radius
The agent can independently react to changes, such as when a portal’s user interface is revised, an additional dialog appears, or a filter does not offer exactly the required selection. The agent can also make decisions when requirements do not precisely match the specifications.
In our example, we searched for tenders within a 50 km radius, but the portals offered only 20, 40, or 60 km. The agent selected 60 kilometers. Setting it to 40 kilometers would exclude tenders from part of the desired area and could miss suitable tenders; the larger setting captures the entire target area but may include additional matches between 50 and 60 kilometers. In those cases, we need a technical rule: can we filter out these matches based on more precise location details? Or do we mark them so that someone manually checks the distance?
Similar questions arise with other filters. What should the agent do when a performance category has a different name than expected? What information does a match need before it can enter the internal system? And how does the process recognize that the team has already transferred the same tender into the target system? The more precisely we clarify these cases in advance, the more reliably the team can work with the results.
Portal access, search rules, data transfer: what needs to be clarified in advance
To get started, it’s worth reviewing the portals your team currently uses. Which of these offer direct data retrieval? Where do employees need to log in? Which filters do they set for almost every search, and which information do they subsequently transfer into the internal system?
Then select a typical search run and check it step by step. This often reveals the rules experienced employees already apply without writing them down, such as choosing 60 instead of 40 kilometers. Once these rules are defined, you can determine the appropriate automation and necessary controls much more easily.
Then comes the question of suitable automation: an API interface enables direct data retrieval, the simplest case. For a few search runs, manual research may still be adequate; if there are stable click sequences, classic browser automation using RPA may be sufficient. A computer-use agent is particularly interesting when the search run follows visible interfaces and involves different dialogs or selection options along the way.
Four questions before starting
Before implementation, companies should clarify four points:
Which portals are relevant?
Frequency of use, login procedures, and available search filters determine the effort involved.
What criteria apply?
This includes performance areas, regions, or search radii – including rules for filters that are not precisely available.
What information should arrive in the target system?
Returning as JSON requires a defined data format and rules for missing or ambiguous results.
Where will human review take place?
The responsible employees in the described process retain the technical assessment and the decision to submit an offer.
Conclusion: Research becomes part of the sales process
Our PoC shows how a computer-use agent can search procurement portals without suitable interfaces and prepare the results for Dataverse. In production, the agent would take over portal searches and prepare the results for the internal system. Instead of collecting tenders from several portals and transferring them manually, the team could use their technical assessment experience: do the requirements match our services? Are deadlines feasible? Is an application worthwhile?
This approach can be easily transferred to other processes where employees regularly collect information from web interfaces. A computer-use agent can relieve them of this preliminary work and import the results into existing processes. However, for each process, it remains essential to define which tasks the agent takes over and where people review and decide.
Where Does AI Really Create Value for Your Company?
Find out with our free, one-hour AI Discovery Call! We will discuss together which application areas are suitable for your organization and what a realistic implementation effort would be.
- confidential
- free of charge
- inspiring
FAQ on automated tender research
A computer-useagent in Copilot Studio can interact with visible web pages. In our example, it navigates procurement portals, applies defined filters, and returns selected information in a structured format.
It suits companies that regularly participate in public tendering processes and therefore search multiple portals for suitable contracts. This includes construction and infrastructure, healthcare and pharmaceuticals, IT, energy, transport, water, waste management, and social services.
The agent returns the selected information as JSON. A downstream process can retrieve this data and make it available in Dataverse.
No. The described process automates research and data transfer. Responsible employees handle the technical assessment and the bid decision.
This depends on the interface and the process. For stable, simple click sequences, classic RPA may be sufficient. If the portals must be operated via the browser and require additional dialogs or changing intermediate steps, a computer-use agent may be better suited. Still check for a suitable API or EDI interface first, as this is the simplest technical solution.
