This article does not describe a specific client or a completed production deployment. It presents a composite scenario based on problems that companies often face when they prepare quotes after a visit or field intervention. The messages, roles and steps below are illustrative.
The requirement is easy to state: a field worker describes a request in Telegram, then a system prepares a draft in the quoting tool and updates the CRM. The intermediate controls are the difficult part. An agent must not invent a product reference, choose a discount on its own or send a commercial commitment without approval.
The problem this scenario is designed to address
In a joinery, maintenance or installation company, the information required for a quote may arrive as a voice note, photo, message, document or phone call to the office. The person preparing the quote then needs to identify the customer, match products, check measurements and request anything missing.
Automation can reduce re-entry when the source data is reliable enough. It cannot fix an inconsistent catalogue or commercial rules known by only one person.
Before connecting an AI model, the business therefore needs to answer a few questions:
| Area to define | Decision required |
|---|---|
| Catalog | Which source contains valid product references and prices? |
| Discounts | Who may propose them, and who must approve them? |
| Required data | Which missing fields must block draft creation? |
| CRM | How should the system identify an existing customer and avoid duplicates? |
| Sending | Which role reviews the quote before delivery? |
| Incident handling | What should the team do when an API or model is unavailable? |
Without these decisions, the agent would move errors around rather than reduce them.
Telegram is one possible channel
Telegram is suitable only when the business already permits it for this use and its security policy allows the relevant data to pass through it. The same workflow could start in a mobile form, Teams, Slack or a business application.
The channel should match the team's habits without bypassing internal rules. For a Telegram bot, the business should at least protect its token, restrict authorized users, define message retention and avoid sending unnecessary data. API secrets must never appear in a conversation.
A voice note may make data entry easier after an appointment. It also introduces transcription and ambiguity risks. If noise hides a measurement or product reference, the system should ask for confirmation instead of filling in the value.
A conditional workflow architecture
A quote workflow could follow these steps:
- The bot verifies the user's identity and accepts a text or voice message.
- The system transcribes the voice note if that feature is enabled.
- The model extracts expected fields into a defined structure: customer, site, products, dimensions, options, requested timing and internal notes.
- Deterministic rules check required fields and formats.
- The CRM searches for an existing customer. An uncertain match triggers a confirmation request.
- The quoting tool provides authorized references and prices. The model does not create its own price.
- The system prepares a draft without sending it.
- An authorized person reviews the content and decides whether to send it.
- The workflow retains the events needed for audit under the business's retention policy.
This architecture can be orchestrated with n8n or a comparable automation tool. An AI agent interprets the request and asks for missing information. Pricing rules, permissions and quote status remain controlled by business systems.
A fictional conversation example
The following message only illustrates the workflow logic:
Prepare a quote for two custom windows with renovation installation. The measurements are in the visit record. The customer also wants a mosquito-screen option and asks whether a discount is possible.
The agent does not yet have everything it needs. A cautious response could be:
I found the visit record, but one measurement has not been confirmed and the request includes no authorized discount rate. Can you confirm the measurement and refer the discount to the authorized reviewer?
Once those points are confirmed, the system can generate a draft using catalog references. It should show the source of each important value so the reviewer can distinguish supplied data, values read from business tools and items still awaiting confirmation.
This example demonstrates expected behaviour for an incomplete request. It does not prove a time saving or any other business result.
What the model can do and what it must not decide
The model can classify an intent, extract fields, rewrite a note and ask a focused question. It can also suggest a match between field terminology and catalogue labels.
Decisions that create a commercial commitment need explicit controls:
- customer identity and billing address;
- dimensions and quantities;
- selected product reference;
- price from the active catalogue;
- discounts and commercial terms;
- contractual wording;
- final quote status and delivery.
A model's suggested match is not approval. When uncertainty remains, the workflow should stop or return the item to a person.
Errors to design for before development
The scenario looks linear in a diagram, but edge cases determine whether it can be trusted.
An ambiguous request
A term used by the team may correspond to several references. The system should present options or ask for clarification. It should not select one silently.
A duplicate customer
Two records may have similar names. An email address, phone number or business identifier can help, but an uncertain match should remain pending.
An outdated price
The catalogue should expose a version or effective date. If the workflow cannot confirm the active price, it should not create a quote presented as ready to send.
An unavailable API
The message should enter a visible pending state. Repeating an action without idempotency controls could create several drafts for the same request.
A hostile or out-of-scope instruction
Incoming content must not be able to change system rules, reveal secrets or grant additional permissions. Permissions are defined outside the message and checked for every sensitive action.
Testing without using staff as test subjects
Testing can begin with anonymized records and known cases. The team compares extracted fields with expected data without writing to production tools.
A draft-only phase can then expose the system to realistic phrasing. Each correction should be classified as a transcription issue, customer identification problem, product reference error, business rule gap or integration failure. This prevents the team from trying to solve every problem in the prompt.
Production use should start only after the business defines a manual fallback. If the bot stops working, the team needs a way to submit the request through the usual process and find any pending messages.
Human approval in production is particularly important for quotes. It protects the customer, sales representative and business from an action based on misunderstood data.
Measuring the outcome without predicting it
Measurement starts with a baseline. Before automation, the business can track:
- time between the request and draft creation;
- requests for additional information;
- drafts corrected before sending;
- errors involving references, quantities or customers;
- actual use of the channel by the intended team;
- technical incidents and manual recovery.
The same indicators are observed during the pilot. A workflow that speeds up entry but increases corrections is not ready. If users bypass the bot, the channel or sequence needs to change.
The same method applies to Pennylane invoicing automation with n8n or an AI sales-call analysis pipeline. Outcomes depend on data quality, explicit rules and human control, not only on the selected model.
When this scenario is a reasonable fit
This type of agent may be worth testing when quotes follow explicit rules, products can be identified in a reliable source and a person can review the draft. It is a poor fit when every offer requires an unstructured technical study, prices are not maintained or no system records approvals.
A reasonable goal is to prepare a more complete file, flag uncertainty and leave the commercial decision with the responsible person.
Also available: Read in French