Automation & AI 9 min read · published on 15 October 2026 · updated on 15 October 2026

Quote requests: how to organize them before automating?

Wail Saidani Wail Saidani Founder of DevDream
Summarize this article with: Claude ChatGPT Perplexity Le Chat Grok
Illustration: a large mail sorter and characters organizing cards in a workshop.
Illustration: gathering requests before planning how to handle them.

To organize quote requests for your trade business, gather them in one place, record the useful details and give each request a next action. Separate missing information, points that need your judgement and requests ready for someone to handle. Automation comes later, once these rules can be tested without sending replies or committing your business.

How do you organize quote requests before automating?

Start by describing how you organize requests today: where they arrive, what you read and how you decide what happens next. The aim is a clear record with an action and a person responsible. This stage does not involve calculating a price, promising a visit or creating the quote.

A website message, a phone call and an email may concern the same job. Conversely, someone you already know may request two different jobs. Keep a separate reference for each request, with its associated messages.

  • Incoming channels: list the channels you actually use.
  • Tracking location: choose the spreadsheet or software where requests can be found.
  • Follow-through: identify who reviews requests and how they see those waiting for action.

Organizing requests should establish the next action, rather than judge a customer's value. A short request may simply lack context. Before changing tools, see whether a spreadsheet can already support this process. The guide to automation uses for tradespeople explains the stages that may come next.


What information should you record?

Record enough information to understand the need, locate the work and get back in touch. Include its source: the original message, form or call notes. Separate what the person said from what you have confirmed. The record helps you review the request; it should not turn a vague statement into a certainty.

Illustration: characters examine files and spot incomplete cards on a review table.
Illustration: spotting missing information and keeping decisions with a person.

Blank worksheet to adapt to your trade and incoming channels

InformationFill inPurpose when organizing requests
Reference and receipt____ / date ____Find the request without creating it again.
Channel and source____ / link or reference ____Reread the original message.
Contact method____Ask for clarification.
Work described____ / to confirm ____Understand the stated need.
Town or area____ / to confirm ____Check whether it is in your service area.
Preferred timing____ / not specifiedIdentify an expectation to review.
Next stepsStatus ____ / action ____ / person responsible ____Know who takes over and why.

For an initial check, the town may be enough to confirm the area. A full address, photo or measurements can wait if they do not yet help determine the next step. Separate required fields from optional information, then explain what each is used for.

Good to know. CNIL, France's data protection authority, recommends limiting data to what the business needs and access to authorized people. Its first-steps guide also calls for informing people when collecting their data, including the purpose, the basis for using it, recipients, retention and their rights. Prepare these points before connecting your tools.

Missing information should stay missing, rather than be guessed. Keep the original request accessible to authorized people under your retention rules. When clarification arrives, add its source: the updated record should still be explainable.


Which statuses help prevent forgotten requests?

Use statuses that identify the next action: 'to complete', 'to review' and 'ready to handle'. Also record the reason and the person responsible. A complete record may still need review, for example if the requested timing seems incompatible with your work. Complete does not mean accepted or ready to price.

Suggested status checklist, to adapt to your process

StatusWhen to use itNext action
To completeRequired information is missing.Identify the clarification to request.
To reviewUncertainty, a contradiction, stated urgency or a possible duplicate.Have the designated person review it.
Ready to handleThe required information is present, with no outstanding point to review.Assign the next step to the designated person.

If several reasons apply, keep them together. A request described as urgent with no location must remain flagged for a person to review, even if the record is incomplete. Set this order of priority before automating.

For a possible duplicate, compare the exchanges without deleting the second message. Check the contact, the work and the location: the same phone number does not prove it is the same job. Once the connection is confirmed, attach the messages to the correct record.

A request marked 'to review' needs a person responsible, rather than just a color. Create a view of requests waiting for action. Reminders about quotes already sent belong to a different stage, covered in the guide to quote follow-ups.

Let's set the rules before connecting the tools. 5.0/5 on Google · 16 reviews
Let's talk

Which rules can a tool follow?

Start with operations whose expected outcome you can explain: recording receipt, reading a completed field, flagging missing information or suggesting a category. Keep decisions with a person when the request needs trade expertise or contains an ambiguity. Artificial intelligence, software that can analyze text among other things, is not needed for every operation.

France Num, the French public portal for business digitalization, recommends describing the stages, information, exceptions and people responsible before automating, in its guide updated on 9 July 2026.

  • Condition: 'If the town is not provided…'
  • Outcome: '…flag the missing location in the record.'
  • Limit: 'If the message says it is urgent, request a person's review.'
  • Record: keep the reason, the rule applied and the classification date.

Write each rule with an observable result in this way. 'Serious request' is not one: two people may interpret the word differently. 'Town missing' can be checked, provided you verify that the information is not simply elsewhere in the message.

Classifying a request does not authorize the tool to accept a job. Leave automatic rejection, announced prices and promised dates out of the first trial. If a summary is suggested, keep the original text to check that its meaning has not changed.


How do you check the process before activating it?

Compare the tool's result with the expected classification on test requests, without contacting anyone or changing active records. Start with examples created for the trial, then plan a controlled check using real requests. Also check what happens when processing fails: an incoming request must remain findable.

Illustrative test cases, without real customers or business results

Test requestExpected resultCheck
Work described, town missingTo complete, reason 'location missing'.No location added through guesswork.
Two messages about a possible shared projectTo review, possible connection suggested.Both originals kept, no merge without review.
Stated urgency, incomplete informationTo review, a person's review flagged.No work date promised.
Complete record, rules metReady to handle, person responsible identified.No quote or acceptance sent.

Add a failure test and process the same message a second time. Check that errors are flagged and a retry does not create multiple records. Record discrepancies and the corrections agreed.

France Num recommends testing the data transferred, action order and notifications before activation. A failed classification must leave a request that someone can take over. Identify who monitors these failures and how to return to manual processing. You can then use this record to prepare the points to check in an automation proposal.


What questions should you ask before starting?

You can start with the tools you already use if requests remain findable and actions visible. Choose software after defining the rules. These questions help check whether the first trial already involves a decision that should stay in your hands.

A spreadsheet may be enough to begin if you can find requests, their source and the next action. Customer management software brings conversations and follow-up together; it is an option to examine when your process needs it. Start by describing what your current approach lacks.

Yes. Completed form fields already allow you to apply clear rules, such as flagging a missing town. Analyzing free-form text needs more checks. See the possible uses for tradespeople to distinguish a simple task from a step that needs your judgement.

I recommend marking it 'to complete' and identifying the clarification needed. If there is also uncertainty or stated urgency, flag it for a person's review. Missing information does not prove that the project is unsuitable, and an automated classification should not decide on its own whether to take it on.


What should be ready before you automate?

Prepare a shared record format, explained statuses, written rules and tests with known outcomes. Each request keeps its source and a person responsible. I recommend making this manual process consistent before connecting your tools, so you can spot exceptions without committing to a job.

Summary: what to prepare before connecting your tools

QuestionKey pointMistake to avoid
What information?What is needed, its source and points to confirm.Filling fields through guesswork.
What happens next?A status, a reason and a person responsible.Confusing a complete record with an accepted job.
What evidence?Checked tests and a way to take over after failure.Activating sending before checking classification.

To define the scope of automation suited to your business, gather your incoming channels and the questions you currently ask. You can talk to me to review this process.

Portrait of Wail Saidani, founder of DevDream
Published on 15 October 2026 · updated on 15 October 2026 Wail Saidani

Founder of DevDream, a web and AI workshop for contractors and small businesses in Villeneuve-la-Garenne, near Paris, France (92). I build websites and set up automation around the tools small businesses use.

Follow me on LinkedIn →

Let's plan how to organize your requests.

Your messages, useful information and decisions to keep in your hands: let's prepare a clear process.

Discuss my project →