Data Inventory Before Quotation Automation: 8 Areas to Review in the Workshop

Before piloting quotation automation, the information the process actually relies on should be clear. This includes more than customer and product data. Original documents, document versions, commercial details, responsibilities and handovers between existing systems are equally important.

This data inventory provides a practical working document. In the workshop, a specific quotation case is examined across eight areas: What comes in? Which details are added? Where do product and pricing information come from? Who decides? And where does the case move between people or systems?

The following Trixner Working Model is not a universal standard. It is an editorial checklist that helps a company examine its own workflow in a structured way. Each review area therefore ends with questions, not a prescribed solution.

Select a real, representative quotation case for the inventory. The first pass is not about finding the perfect solution. It identifies the information, decisions and handovers that actually occur today.

Use four simple states at each stage:

• Available: The information is clearly named and can be found.
• Unclear: There are several possible sources or differing interpretations.
• Missing: The information is not available in the selected case.
• Not relevant: The information is deliberately not required for this type of enquiry.

The result is not a theoretical data model, but a working view of the current process.

Begin by identifying the channels through which an enquiry arrives and what must be retained as the original. Examples include email, a form, a personal conversation or an existing customer portal. Review attachments separately because one message may contain several types of document.

• Through which channels can a case begin?
• Which message or file is considered the unaltered original?
• How are later additions assigned to the same case?
• Which file formats should be processed, stored only or reviewed manually?
• How does the person handling the case know that new documents have arrived?

Next, define the details that describe the business context. A case number may be a sensible option, but another unique assignment can also work initially as long as it remains traceable within the company's workflow.

• How are the company, contact person and delivery address distinguished?
• Which existing customer or project reference should be retained?
• Which language and communication channel should be used?
• Which details may be adopted automatically and which require visual review?
• How are new contacts or senders who cannot be assigned unambiguously handled?

This area describes what is being requested. Derive the required attributes from the company's own products and services. A limited type of enquiry with a manageable set of attributes is sufficient for a pilot.

• Which product group or service is intended?
• Which attributes must be available for specialist review?
• Which variants could be confused with one another?
• Which customer requirements must be observed?
• Which details must never be guessed or copied from similar cases?

A missing value remains visible in this model. It is passed on as an open question instead of being filled in through plausible wording.

Documents should not be assessed by filename alone. Additional attributes may help with processing, such as document type, relation to the case, approval status or the version identifier used by the company. Which of these are useful depends on the workflow.

• Which types of document occur in the selected process?
• How is a new version distinguished from an addition?
• Who decides which version to use when information conflicts?
• Which documents must be reviewed together?
• How do superseded documents remain traceable?

Technical and commercial information should be shown separately in the inventory. This makes it possible to define who may review which details and which approved source they must come from.

• Which quantity, unit and volume tiers are required?
• Which requested date and delivery location were specified?
• Which pricing or terms source should be used?
• Which assumptions are permitted and how are they identified?
• Which details may enter the draft only after commercial approval?

Assign a responsible role to each decision point. This does not necessarily mean one specific person. What matters is that the selected process clearly states who should review, add information, approve or reject.

• Who performs the initial review?
• When are sales, engineering, purchasing or costing involved?
• Which decision requires approval by a named person?
• What happens when the responsible role is unavailable?
• Which information does the reviewer need to make a sound decision?

Now map how information moves between the existing tools. Start by observing where information is read, added, copied and entered again.

The table is a template. Replace system names and roles with the company's actual environment.

Finally, collect cases that must not continue automatically. A good inventory therefore covers not only the normal path, but also uncertainty and stop conditions.

• Which missing details trigger a follow-up question?
• Which contradictions must be escalated to a specialist role?
• Which documents or product groups remain fully manual initially?
• How is an unclear case marked and resumed later?
• Which information must be retained in the review log?

For an initial workshop, each review area can be recorded in one row:

Turn the open points into a short clarification list. Only then decide which part of the process should be supported by rules, search, a workflow or AI.

The inventory creates a shared view of data, documents, roles and handovers. It does not promise automation, but it shows which questions should be answered before a pilot and where controlled support may be feasible.

Further Reading: The article Automating Technical Customer Enquiries: From Email to a Verifiable Quotation Draft.

To review your own workflow using a specific case, see Data & AI Readiness for the appropriate next step. Together, we can turn this into a prioritised clarification list and a realistically scoped pilot.