Prepare a catalogue project around one buyer and one reviewer

Before listing features, choose a request that should work from beginning to end. It should contain enough detail to expose the real decisions without requiring private customer information. A fictional item, sample document and staff role are sufficient for the initial discussion.

Describe what the buyer knows

An exact item reference, a product family and an application description are different starting points. State which one your buyer has. Then identify the public information that helps them continue: a comparison, a document, a limitation or an explanation of the review service.

Do not make the example artificially complete. If a buyer normally lacks a drawing revision or a final quantity, include that uncertainty. The process needs an honest way to handle it.

Describe the receiving decision

What should staff do with the request? They may identify the relevant item, ask for clarification, assess a supplied specification or prepare a quotation. These steps have different information requirements and may involve different people.

Record the next authorised role and the source they consult. If the request can be claimed by more than one reviewer, explain how responsibility is assigned. If a colleague returns it to the queue, explain what the next person needs to see.

Map the sources before proposing a connection

For each important value, name its current owner. A supplier feed may identify a component, while your product owner controls its public description. A document store may hold a file, while the request record identifies why it was supplied. Those relationships should not be reduced to a list of software names.

Bring safe examples of the actual format where possible. Unknown fields and account permissions can become discovery tasks rather than assumptions in the implementation estimate.

Name the content and language work

Identify what already exists, what needs rewriting and what needs technical approval. A translated page does not guarantee an equivalent document. A readable Czech heading does not prove that a generated message is correct.

Project conversations and technical delivery are in English unless additional assistance is agreed. Czech translation and professional review are separately arranged. Your organisation names the people who confirm business facts and any local or regulated requirements.

Select the first release and the manual work

The initial delivery may cover one product family, a small portal task or one import. It should reach a useful ending. If staff manually check availability, describe that step rather than presenting an automatic purchase promise.

List deferred work with its owner and trigger. A future integration should extend an understandable current process. It should not be required to explain why the first release cannot complete its stated job.

Agree evidence for acceptance

Write down the ordinary case, a changed input and an exception. Identify the visible customer result and the receiving record. Include a control that must remain unaffected, such as another item or an unrelated customer's document.

The handover sheet is a compact way to collect these decisions. The project brief guide shows how to turn them into a useful initial description. Send the project inquiry when you can explain the task and the first unresolved question.