Articles

Requests in the email inbox: how to capture tenders completely

Before anyone reads a bill of quantities or matches a product, someone has to notice that a request has arrived at all. This article covers the first step of request management: the email inbox, from recognising a request and its required details to ownership in the team.

Abstract illustration: envelopes flow into a central funnel and come out as ordered request cards with a calendar marker.
Introduction
A request email is captured only once customer, project, deadline, documents and owner are clear. Addenda belong to the original request, not to a new case in the list.

Text only

is enough: Scalera reads requests that exist only in the email text, without an attachment (Scalera, FAQ)

around 30

new tenders a team sifts through by hand each morning in the example day on the product page (Scalera, Product Matching)

+15–30%

win probability in competitive tenders through faster response at dormakaba (dormakaba case study)

2018

from 18 October at the latest, EU-wide public procurement must communicate electronically (Directive 2014/24/EU)

As of 11 Nov 2026. Resource type: article. Statements about Scalera come from the FAQ, the product page and the dormakaba case study on scalera.ai; details on procurement, email header fields and shared mailboxes come from Directive 2014/24/EU, RFC 5322 and Microsoft Learn. All sources opened on 11 November 2026. Editorial recommendations are marked explicitly.

Short answer

  • Recognise: Every email with positions, quantities or documents for a project is a request, even without an attachment.
  • Capture: Customer, project, deadline, documents, delivery date and location go on one request card.
  • Link: Attach addenda and questions to the existing request instead of opening a new case.
  • Assign: One shared address for requests, clear rules by region or product group.
  • Then: Prioritise, read the bill of quantities, match products.

Scope: this article covers intake. Prioritisation and bid/no-bid are in the guide «Bid or no bid».

Why does request management start in the inbox?

Because every deadline runs from the moment a request arrives, not from the moment someone notices it. If an email sits unread in a personal mailbox for two days, those two days are missing later in pricing.

The inbox is also where requests arrive in the least consistent form. In EU-wide public procurement, electronic communication has been mandatory since 18 October 2018 at the latest (Directive 2014/24/EU, Art. 22 and 90). Between contractors, dealers and manufacturers there is no fixed format: sometimes a complete bill of quantities arrives, sometimes three lines of text.

The example day on Scalera's product page starts with around 30 new tenders that are sifted through by hand and prioritised by guesswork (Scalera, Product Matching). Before that list can be sorted, every request has to be recognised as a request and captured completely. That is what this article is about.

What types of request email are there?

Five patterns can be told apart. Each needs a different next step, so it pays to name the type as soon as you open the email.

Five types of request email
Email typeRecognised byNext step
BoQ attachedPDF, GAEB or ExcelCheck documents, capture
Text onlyPositions and quantities in textPull out positions
Platform linkNotice with linkDownload documents
AddendumReply, same projectLink to existing request
QuestionNo new positionsPass to the owner

Own compilation. Platform access in EU procurement: Directive 2014/24/EU, Art. 53; reply header fields: RFC 5322.

The request is only in the email text

Smaller requests, follow-up orders for an ongoing project or quick price checks often arrive without a document. The positions then appear as a list or running text in the email, sometimes below a sign-off or inside a forwarded message.

Example (fictional): «Subject: Request Talacker school. Please quote by Friday, 20 Nov: 36 pcs interior door 85 x 200 cm, 36 pcs stainless steel lever handle set, 36 pcs door stop. Delivery in week 3 to the site in Winterthur.» What gets captured: project Talacker school, deadline 20 Nov, three positions with quantity and unit pcs, delivery week 3, delivery location Winterthur.

If such an email is filed as «just a question», the request is missing from every overview. According to the FAQ, Scalera recognises requests directly in the email text and reads the requested positions with quantities and units where available (Scalera, FAQ).

The email points to a procurement platform

In public procurement, documents are usually not attached but held on a platform. For EU-wide procurement, the directive requires public buyers to offer free, full electronic access to the procurement documents from the date of the notice and to state the internet address (Directive 2014/24/EU, Art. 53).

The email is then only a pointer. The request is captured once the documents have been downloaded and filed with the request card. How to turn a PDF bill of quantities into checkable positions afterwards is shown in the guide Bill of quantities from PDF and scan.

Which details does a request need before anyone prices it?

We recommend a request card with seven fields. It is created on arrival and stays with the request until the quote. If a field is missing, note it and ask the customer before pricing starts.

  1. Customer and contact: company, name, phone. For forwarded emails, the original sender, not the person who forwarded it.
  2. Project: name and location as the customer states them. This is the most important key for linking addenda later.
  3. Submission deadline: date and, if given, time. If the email has no deadline, ask for it rather than guess.
  4. Documents: attachment, platform link or positions in the email text, with a note on whether they are complete.
  5. Delivery date and location: where given, because they affect availability and freight.
  6. Owner: one responsible person, not «the team».
  7. Status: new, being clarified, in progress, submitted or declined.

What the bill of quantities itself contains, such as item types, long texts and preliminary notes, does not belong on the card but in the content review. See the article Analyse a bill of quantities with AI.

By checking every new email against the open requests first and only then opening a new case. Addenda with changed quantities, new positions or a moved deadline are risky when treated as a separate request: you end up with two quotes, one of them outdated.

The email standard helps. According to RFC 5322, every message should carry a unique «Message-ID», and replies should also carry «In-Reply-To» and «References». Email clients build conversations from these. The link is not always enough, though, because a customer can send an addendum as a new email with a different subject.

We therefore recommend a simple rule for every incoming email:

  • Same conversation: link to the existing request and note the change.
  • Same project, same customer: check as an addendum, even if the subject is new.
  • Same project, different customer: separate request. How to handle projects requested several times is covered in the guide Bid or no bid.
  • New document version: keep the old version, mark the new one as valid and flag affected positions.

Who owns it: shared mailbox, region or product group?

First you need a shared entry point. We recommend giving customers a team address for requests instead of personal addresses. Microsoft describes shared mailboxes for exactly this case: several people access the same mailbox and, with the right permissions, can send on its behalf (Microsoft Learn). Other email systems offer comparable features.

Then you need a rule for who takes over. Three models are common, and they can be combined:

  • By region or customer: the person who knows the customer takes the whole request.
  • By product group: large bills of quantities are split so specialists only handle their positions.
  • By volume: large requests go to a central team, small ones to regional inside sales.

For splitting by product group, Scalera categorises positions by product groups according to its FAQ, so team members can filter and work on their sections (Scalera, FAQ). If you pass requests on to dealers or partners rather than only internally, the process is described in the article Tenders in partner networks.

A request nobody recognised as a request is not lost to the competition. It is lost in the inbox.

What does Scalera take over when requests arrive?

According to the FAQ, Scalera processes emails with free text or attachments, as well as PDFs (scanned and digital), GAEB, Excel/CSV and XML (Scalera, FAQ). If the request exists only in the email text, it is recognised there, and Scalera takes over positions, quantities and units where the email contains them (Scalera, FAQ).

New tenders are ordered by estimated contract volume and duplicates are flagged, according to the product page; on opening, the positions are already pre-extracted and sorted into categories (Scalera, Product Matching). Requests in German, English, French, Italian, Spanish and other major European languages are supported, according to the FAQ (Scalera, FAQ).

What faster intake can mean for the business is shown by dormakaba: according to the case study, improved response times increase win probability in competitive tenders by 15–30%, and partners process 2–3× more tenders with the same resources (dormakaba case study). If you need supplier prices for a request yourself, the article Automate supplier price requests covers the next step.

How do you know the inbox is under control?

We recommend four simple metrics you can read from the request list without new software. What matters is the trend over a few weeks, not a single value.

  • Time to capture: hours between the email arriving and a complete request card.
  • Share of complete cards: how many requests have all seven fields at first capture?
  • Unlinked addenda: how often was an addendum linked late, or not at all, to the original request?
  • Tight deadlines: how many requests reach the owner only shortly before the deadline?

If one of these numbers rises, the cause usually sits before pricing: unclear ownership, personal mailboxes or missing required details.

Key takeaways

  • Request management starts with the email, not with the bill of quantities.
  • Five email types need five different next steps; plain-text emails are requests too.
  • A request card with seven fields makes missing details visible before pricing.
  • Addenda belong to the existing request; conversation, project and customer are the keys to check.
  • A shared request address and a clear ownership rule keep requests from getting stuck in personal mailboxes.

Want to see how Scalera recognises requests in your email traffic? You can book a demo and bring two or three typical request emails.

Frequently asked questions

Is an email without an attachment a real request?

Yes, as soon as it names positions or products, quantities and a reference such as a project or a deadline. Capture such emails exactly like a bill of quantities sent as an attachment. According to Scalera's FAQ, the email text alone is enough; no attached document is needed (Scalera, FAQ).

What if the email only points to a procurement platform?

Download the documents there and only treat the request as complete afterwards. For EU-wide procurement, public buyers must offer electronic access to the documents from the date the notice is published, and the notice names the internet address (Directive 2014/24/EU, Art. 53).

Shared mailbox or personal mailboxes?

For requests we recommend a shared address the whole team can access. Microsoft describes shared mailboxes for exactly the case where several people need access to the same mailbox (Microsoft Learn). Personal mailboxes remain for ongoing coordination with the customer.

How do I recognise an addendum to an open request?

By its link to the same email conversation and the same project. According to RFC 5322, replies usually carry the «In-Reply-To» and «References» header fields. Because forwarded or newly written emails can lose this link, also check project, sender and deadline.

Which details does a request need before anyone prices it?

Customer and contact person, project, submission deadline, complete documents or positions with quantities, requested delivery date and delivery location, and one responsible person. The request card in this article lists the fields in detail.

Can Scalera read requests in other languages?

According to its FAQ, Scalera supports all major European languages, including German, English, French, Italian and Spanish (Scalera, FAQ).

Does capturing requests in the inbox replace the bid/no-bid decision?

No. Capturing makes sure every request is in the list, complete and assigned. Whether you bid is decided afterwards; see the guide Bid or no bid.

Sources

  1. FAQ on scalera.ai, opened on 11 November 2026
  2. Scalera product page (Product Matching), opened on 11 November 2026
  3. dormakaba case study on scalera.ai, opened on 11 November 2026
  4. Directive 2014/24/EU on public procurement, Art. 22, 53 and 90 (EUR-Lex), opened on 11 November 2026
  5. RFC 5322: Internet Message Format, section 3.6.4, opened on 11 November 2026
  6. Microsoft Learn: About shared mailboxes, opened on 11 November 2026