Automation can spot a quotation request that needs a technical scoping call by checking whether the deliverables, required inputs and dependencies are clear enough to price. When unresolved choices change the work, prepare a focused agenda for a technical reviewer. When only a factual detail is missing, ask a written question first.
The decision is about readiness for quotation. A promising customer may have an unclear request, while a brief enquiry may describe a familiar service precisely. Check what remains unresolved before choosing the next step.
Define what makes a request ready for quotation
Start with one established service and list the information your estimator actually needs. For a website update, this might include affected pages, replacement content, functionality changes and who approves completion. For an integration, it might include systems, records exchanged, transfer direction and responsibility for failed transfers.
Describe the finished outcome. “Connect our systems” leaves several interpretations open. “Send confirmed shop orders into the stock system and show rejected records to an administrator” gives the reviewer a clearer starting point.
Record boundaries too. Does the request include cleaning old records, changing an existing system or ongoing support? These proposed intake checks should reflect your service, rather than becoming a universal questionnaire.
Within lead generation systems, this step establishes whether an enquiry can progress towards a quotation. Keep commercial suitability separate: missing scope information should not silently become a reason to reject the lead.
Separate missing facts from technical uncertainty
Label each required input as confirmed, missing or ambiguous. Preserve the supporting sentence or document reference. If an attachment is unavailable, record that limitation rather than treating the request as fully inspected.
A missing fact is something the customer can supply directly: affected page links, system name or preferred date. Ask the smallest question that closes the gap.
Technical uncertainty concerns how the work should operate. “Synchronise stock” might mean scheduled updates, immediate updates or changes flowing both ways. Choosing between these could affect design and estimation, making a technical discussion useful.
Distinguish unknown dependencies from confirmed obstacles. “Access has not been checked” does not establish that integration is impossible. State what evidence is needed and who can provide it.
Phrases such as “same as before” deserve inspection. The earlier specification may settle the question, but a previous quote for another project should not automatically define this one. Compare the referenced scope before deciding that a call is necessary.
Use this pre-quotation decision tree
Apply these proposed rules in order. Keep all unresolved questions in the handoff, even when an earlier check determines the immediate route. After clarification, reassess the remaining checks.
Reusable pre-quotation decision tree
| Condition | Proposed next step |
|---|---|
| Identity or project match is uncertain | Sales owner checks the records before another reply or quotation task. |
| Submission is a confirmed repeat of the same request | Associate it with the existing enquiry, preserve its source and check existing handling. Stop a second workflow; continue through the existing owner. |
| Contacts or documents give conflicting requirements | Sales owner asks which requirement applies; retain both versions before reassessing scope. |
| A required customer-supplied fact is missing | Ask a targeted written question, then reassess the request. |
| Deliverables or completion criteria have interpretations that change the work | Technical reviewer prepares a scoping call around those choices. |
| Access, compatibility or third-party responsibility could change the approach | Technical reviewer decides whether documentary evidence or a scoping call will resolve the dependency. |
| Request falls outside established service boundaries, or fit is unresolved | Technical lead determines feasibility, further discovery or referral before quotation preparation. |
| Scope and dependencies are understood, inputs are present and service fit is confirmed | Send to the responsible estimator for quotation review. |
Prepare the handoff:
- Request reference and sales owner: [record both].
- Existing enquiry: [confirmed match, uncertain match or new request; record supporting evidence].
- Customer's desired outcome: [their wording and source reference].
- Confirmed scope: [deliverables, boundaries and evidence].
- Missing facts: [question, person who can answer and why it matters].
- Technical decisions: [choice to resolve and effect on estimation].
- Dependencies: [system or third party, evidence and unresolved access].
- Proposed route: [quotation review / written clarification / technical scoping / duplicate handling / feasibility review].
- Call agenda, if needed: [decision questions and people needed].
- Human decision: [reviewer's name, chosen route and reason].
Completion rule: Prepare a quotation only when the responsible estimator accepts the scope and records remaining assumptions or exclusions. Handle confirmed duplicates through the existing enquiry.
Turn the flag into an agenda someone can use
“Complex request” is a weak handoff. Explain the choice and its consequence: “Both systems may change stock quantities; the ownership rule affects how conflicting updates are handled.”
For that request, the agenda should ask which system owns the quantity, when updates should occur and who handles rejected records. Link each question to the customer statement that raised it. Remove questions already answered in supplied documentation.
Invite people who can settle the gaps. The sales contact may explain the desired outcome while a system administrator confirms available access. Ask for relevant documentation or a representative record, without requesting passwords in the intake reply.
Close the call by recording decisions, exclusions and outstanding evidence. Assign each unresolved dependency to a person. A completed meeting does not make an unverified assumption safe to price; the estimator still needs to accept the resulting scope.
Worked examples: choose the next action
All scenarios and quantities below are hypothetical. They illustrate proposed handling rather than measured results.
Ordinary request: A customer names four website pages, supplies approved replacement text and confirms there are no functionality changes. The work matches the established update service. Expected handling: the sales owner checks the material and passes it to the estimator. No scoping call is needed unless inspection reveals another dependency.
Missing information: Another customer requests page updates but supplies no page links. Expected handling: ask for those links in writing. Keep the request pending and reassess the scope after receiving them. Do not invent a page count.
Ambiguous scope: A retailer wants its shop and warehouse to “talk to each other”. Systems are named, but records, transfer direction and failure handling are unclear. Expected handling: the technical reviewer prepares a call agenda around those choices and requests available system documentation. Hold quotation preparation until the approach is sufficiently defined.
Confirmed duplicate: The same customer resubmits the same request through a form and email. The sales owner confirms both concern the existing enquiry. Expected handling: associate the new source with that enquiry and check whether clarification or quotation work is already underway. Continue with its owner; do not create another estimation task or send a second acknowledgement automatically.
Conflicting repeat: A colleague's email adds stock updates to the original order-transfer request. Expected handling: preserve both versions and confirm whether the addition changes the same project. Once confirmed, reassess technical scope through the existing enquiry.
Unfamiliar service: A customer requests a warehouse control system outside the team's established integration work. Expected handling: the technical lead determines whether further discovery is appropriate or referral is needed. Passing the information checks alone does not establish feasibility.
Build extraction and routing as separate steps
In a proposed AI automation workflow, AI could extract statements and unknowns into consistent fields. Service rules could then produce a route for human review. Keep the extracted evidence visible so a reviewer can challenge the interpretation.
OpenAI documents Structured Outputs for responses that follow a supplied schema. This supports consistent fields; schema conformity does not establish that a scope interpretation is correct. Source: OpenAI Structured Outputs
Function calling allows a model to request application-provided actions, with application code executing them. Enquiry lookups and review-task creation would need their own implementation; the documentation does not provide this quotation workflow. Source: OpenAI function calling
n8n documents approval or denial before selected AI tool calls execute. A proposed setup could apply that review to outgoing clarification messages. Source: n8n human review for AI tool calls
Check current account, plan and region eligibility before deployment. Use the AI agents versus automation comparison, custom AI agent definition and custom AI agent workflow guide when deciding how much interpretation the intake needs.
FAQ: quotation request triage
Should every integration request require a scoping call?
No. Familiar work with confirmed inputs and understood boundaries can reach quotation review directly. Use a call where unresolved choices affect the approach, rather than because the request mentions integration.
What if the customer insists on a price immediately?
Explain which unanswered question affects pricing. The estimator can decide whether a qualified indicative estimate is appropriate and state its assumptions. Automation should not invent deliverables to produce a firm quotation.
How do we check whether requests reach the right route?
Ask sales and technical reviewers to classify sample requests independently. Inspect disagreements, missed dependencies, duplicate tasks and unnecessary calls. Adjust the specific rule responsible. Track later quotation rework separately; agreement on routing does not prove accurate estimation.
If your business needs help turning quotation requests into focused questions and technical agendas, get in touch about an intake workflow shaped around your service boundaries.