A better brief explains who needs help, which task is difficult, what should improve, and what the first release must demonstrate. You do not need to choose a programming language or write a technical specification to provide that information.

Describe the problem before naming the solution

Start with a sentence like this:

Our operations team re-enters approved service requests from email into two systems. We want to reduce repeated entry while keeping a manager's approval before any record is submitted.

This is an illustrative brief, not a client result. It identifies the user, the task, the friction, and an important boundary.

Compare it with “build an AI agent for operations,” which leaves the actual job undefined.

GOV.UK's discovery guidance recommends understanding the problem, users, and constraints before committing to a service build. You can apply the same principle to a small business project without copying a public-sector delivery process.

Use this project brief template

Copy the following sections into a document and answer them in plain language.

1. Business problem

What task takes too long, causes mistakes, or limits the service you can offer? Describe one recent example without including confidential customer information.

Example: Staff copy an approved request into the scheduling tool and CRM. Corrections must then be repeated in both places.

2. Users and current workflow

Who starts the work, who approves it, and who uses the result? List the steps and existing tools. Include what happens when information is missing.

3. Desired outcome

Describe the improvement and how you will measure it. Record a baseline during discovery if you do not have one.

Example: Reduce repeated entry while preserving approval, traceability, and a visible route for exceptions. Measure completion time and corrections before setting a target.

4. First release

List the smallest useful scope. Name included input types, user roles, systems, and outputs.

Example: One request form, one approval role, one destination integration, and a queue for failed submissions.

5. Excluded work

State what can wait. Examples might include a mobile app, additional departments, automatic outbound messages, or migration of the entire historical archive.

6. Constraints and dependencies

Include systems that must stay, access requirements, available sample data, important business dates, and the people who can answer questions. Identify external approvals or vendor features that need checking.

7. Acceptance examples

Describe observable behaviour that someone can test. Include a normal case, an exception, and a failure.

8. Ownership and support

Ask for the expected handover: source code where applicable, deployment instructions, operating documentation, account ownership, backups, monitoring, and support responsibilities. Specify who should be able to maintain the result after launch.

Turn features into acceptance examples

“Reliable integration” is difficult to sign off. This is more concrete:

For AI-assisted steps, also define what the system should do when evidence is missing or an output fails validation. Evaluate a representative set of examples rather than one successful demonstration.

Ask every supplier to expose assumptions

Request that proposals separate confirmed requirements, assumptions, open questions, and optional work. Ask what could change the estimate and what evidence is needed to reduce that uncertainty.

Compare the same scope and handover expectations. A lower initial price may exclude migration, integration recovery, testing, or ongoing maintenance. A larger proposal may include features you do not yet need.

If the workflow is still unclear, ask for a bounded discovery phase with explicit outputs: a process map, a recommended scope, a risk list, and a revised estimate. Agree what decision those outputs should help you make.

Keep the first discussion concrete

Bring the brief, a simple process sketch, and a few sanitised examples. Identify one person who can make scope decisions and one person who performs the task regularly.

You can leave the technology selection open while being very specific about the business result. That gives a developer room to recommend a suitable approach and gives you a clearer basis for judging the proposal.

Plan your project with PlainAI Work

Explore our website development and AI automation services to see where a focused first release could fit.

For a practical companion to this brief, read our custom software development quote checklist.

Ready to discuss your project? Contact us through the PlainAI Work website with your current tools, the task you want to improve, and your desired first outcome.

Another submission creates two records because the integration retried after a timeout. Now two people follow up with the same prospect.

These are illustrative failure scenarios, but they reveal an important requirement: a useful integration must show what happened to each handoff. Connecting two applications is only the starting point.

Define which system owns each value

Before discussing connectors, agree where each piece of information is maintained.

A website may collect the original enquiry. The CRM may own the assigned salesperson and current lead status. Another system may own customer account details after onboarding.

Write down the mapping:

Avoid a vague requirement that “everything syncs both ways.” If two systems can change the same field, define how conflicts are resolved and which changes should trigger another update.

Give every handoff an identity

A submission needs a stable identifier that follows it through the integration. A retry of the same submission should retain that identity.

Some providers deliver events more than once or in a different order from the one you expect. For example, Stripe's webhook documentation explicitly describes duplicate events and delivery ordering limitations. Check the delivery contract for each service you actually connect rather than assuming they all behave identically.

Ask the developer how duplicate handling works when two copies arrive together. A “check, then create” sequence can still produce duplicates if both copies pass the check before either writes a record.

A robust design may combine an atomic claim on the submission identifier with a unique external reference or an idempotency feature at the destination. The exact mechanism depends on the systems involved.

Handle the ambiguous timeout

The difficult case is not always a clear error. Sometimes the CRM accepts a record, but its response never reaches the integration.

Blindly creating the record again can duplicate it. Marking it successful without checking can hide a failure.

The proposed design should explain how it resolves an uncertain outcome: for example, by querying the destination using the stable reference, or safely repeating the same request when the destination supports that behaviour.

This is a useful question for a supplier demonstration: “Show me what happens when the CRM accepts the lead but the acknowledgement is lost.”

Make failures visible to the team

Use states people can understand, such as received, waiting, delivered, needs review, and failed. Each item should include a timestamp, a reference, the last meaningful error, and the next available action.

For a webhook-driven design, acknowledge a valid request only after it has been accepted durably for processing. Use background processing when needed, and validate incoming requests according to the provider's documented mechanism.

Limit automatic retries and explain what happens after they are exhausted. Retrying a temporary outage can help; repeatedly retrying an invalid field will usually need a correction instead.

Assign an owner to unresolved items. A queue that nobody checks merely moves the problem to another screen.

Reconcile what you expected with what arrived

A successful delivery response is useful, but an operational check should also compare source submissions with destination records.

Ask whether staff can answer:

• Which submissions have not reached the CRM?

• Which records have a duplicate external reference?

• Which items are waiting for correction?

• Can a corrected item be retried without creating a second record?

Choose a reconciliation frequency that fits your business volume and response expectations. Keep logs focused on useful diagnostic information instead of copying unnecessary personal data into every event.

Test before replacing the manual handoff

Include these acceptance scenarios in the project scope:

1. A normal submission creates the intended record with the correct fields.

2. Two deliveries of the same submission produce one business record.

3. A temporary destination outage preserves the submission for recovery.

4. An invalid field creates a visible exception with a useful explanation.

5. A lost acknowledgement can be resolved without an uncontrolled duplicate.

6. A later retry does not reset information your team has edited in the CRM.

For a broader enquiry workflow, see our guide to starting with customer enquiries.

Plan a reliable connection between your systems

See our API integration services for connecting websites, business tools, and internal workflows. Our API integration requirements checklist can help you prepare field mappings, ownership, and recovery expectations before development.

Connecting a website, CRM, or internal tool? Contact PlainAI Work through our website. Tell us which systems need to exchange information and what currently gets lost, repeated, or delayed.

AI-assisted document processing can help with this repeated data entry. But a useful solution needs more than text extraction. It needs a clear definition of the required data, checks that reflect the business, and a review step for uncertain or inconsistent results.

Consider this illustrative use case: a distributor receives customer order forms in several layouts and wants to prepare draft orders for staff to review.

Define the output before selecting the extraction tool

Start with the fields needed for the next business step. For an order form, those might include a customer reference, delivery address, product code, quantity, and requested date.

Create a field checklist:

These rules are examples, not universal defaults. A business owner should define what is acceptable for the actual workflow.

Separate reading from understanding

Optical character recognition, or OCR, identifies text in an image or scan. Extraction maps information into fields. Business validation checks whether those fields make sense for the intended use.

Those stages can fail independently. Text may be read correctly but assigned to the wrong field. A quantity may be extracted accurately while its unit is omitted. A correct product code might refer to a discontinued item.

Microsoft's document extraction guidance discusses confidence at different levels and the role of human review. Confidence is useful evidence for routing work; it should not replace your acceptance rules or tests on representative documents.

Build a visible review queue

A practical first release could follow this sequence:

Document received → fields extracted → rules checked → staff review → draft order saved.

The review screen should show the source document beside the proposed fields. Highlight missing values, failed checks, and the passage or page from which a value was taken when available.

Give staff distinct actions: correct a field, approve the draft, request clarification, or reject the document. Record the decision and keep it connected to the source.

Do not silently turn an unclear value into a plausible default. If the system cannot determine whether “10” means boxes or individual units, that uncertainty belongs in the review queue.

Test the awkward documents

Collect a representative sample that you are authorised to use. Include normal files and the cases your team already finds difficult:

• Scanned and digitally generated PDFs.

• Rotated pages, poor scans, or faint text.

• Multi-page tables and repeated headers.

• Different suppliers or customer layouts.

• Missing fields and handwritten amendments, if relevant.

• The same document submitted twice.

Keep some labelled examples aside for evaluation rather than using every example during configuration. Otherwise, the demonstration may mainly show how well the system handles material it has already been tuned against.

Measure the full task

Field accuracy matters, but it is not the only measure. Record how often the whole document is usable, how much correction is needed, how long review takes, and whether errors reach the destination system.

Compare the complete assisted workflow with the current manual process. If extraction is quick but checking takes longer than retyping, the project needs a different review design or narrower scope.

Report results separately for difficult document groups. A strong average can hide poor performance on the layout one important customer uses.

Plan the handoff to the business system

Approval is not the same as successful delivery. Show whether a reviewed record is waiting to be sent, was accepted, or needs attention.

Give each submission a stable reference so a retry does not create another order. If the destination times out after accepting a record, investigate or reconcile its status before sending a new creation request.

Agree who owns failed transfers and how the original files and extracted data will be retained. Access should match the people who need the documents for their work.

A useful first project brief

Specify one document family, the required fields, the review rules, one destination, and a named operator. Ask for a working demonstration using your evaluation sample, with the remaining manual steps shown honestly.

That creates a concrete basis for deciding what to automate next.

Connect document processing to your workflow

Explore our AI automation services and API integration services for moving reviewed information into the systems your team uses. For a more focused example, read our AI invoice extraction and human review guide.

Have a recurring PDF-to-system task? Discuss it with PlainAI Work through our website. Describe the document type, the fields you retype, and the destination system without uploading customer documents in your initial enquiry.

An internal AI knowledge base can help with that kind of repeated question. The useful goal is a shorter path to a verifiable answer: a concise response, a relevant source, and a clear indication when the available material is insufficient.

Here is a practical way to scope the work before commissioning an assistant.

Start with one collection and one audience

Choose a bounded use case, such as helping a service team find approved onboarding procedures. Avoid starting with every company document.

Identify the people who will use it, their recurring questions, and the documents they are already allowed to read. Name a document owner who can settle conflicts and approve updates.

A document inventory can be simple:

These are illustrative entries. The important distinction is between current guidance and material that merely happens to be available.

Understand what retrieval adds

Retrieval-augmented generation, often called RAG, retrieves relevant information and supplies it as context for an AI-generated answer. Microsoft's RAG overview describes that pattern, including the role of retrieval, grounding, and citations.

For a business user, the proposed journey should be easy to inspect:

Question → authorised source search → answer with supporting passages → source opened by the reader.

Retrieval does not guarantee that the answer is correct. A system can select an outdated passage, miss an exception, or produce a claim its citation does not support. A visible source makes checking possible; the checking still matters.

Make the answer checkable

Specify what the answer should contain before choosing a model or interface:

• A direct response to the question.

• Links to the documents and sections used.

• Version or review information where available.

• A clear statement when the evidence is missing or conflicting.

• A route to the responsible person for unresolved questions.

For example, if the approved collection says nothing about a requested exception, the assistant should identify that gap. Inventing a plausible procedure would defeat the purpose of using approved material.

For the first release, keep the assistant focused on finding and explaining information. Actions that change business records can be evaluated separately after the answer quality is understood.

Check access before content reaches the model

A person should not receive information through the assistant that they cannot access in the underlying source. Enforce that restriction during retrieval, before passages enter the model's context.

Include access changes in the design. What happens when someone moves teams, a document becomes restricted, or a source is removed? Search indexes, cached answers, and stored conversation history all need an agreed handling policy.

Treat text inside retrieved documents as reference material, not instructions that can override the assistant's rules. Microsoft discusses access controls and untrusted retrieved content in the same RAG guidance.

Test questions the demonstration will not volunteer

Build a small evaluation set with your subject expert. Include:

1. A common question with one clear approved answer.

2. A question that requires information from two documents.

3. A question where an old version contradicts the current version.

4. A request for information the test user cannot access.

5. A question the collection does not answer.

6. A document containing irrelevant instructions addressed to the assistant.

For each, record the expected behaviour and supporting source. Check the answer and the citation together. Also test how quickly an approved correction becomes visible.

Measure task completion, unsupported claims, source correctness, and time spent checking answers. A polished chat window is only one part of the result.

What to ask for in a pilot proposal

Ask the developer to define the included sources, permissions, update process, evaluation set, operating costs, and handover documentation. Request a demonstration of both a successful answer and an intentional “I cannot answer from these sources.”

A focused pilot should help you decide whether better search is enough, whether an AI answer layer adds value, and what work is required to maintain the knowledge.

Plan an internal knowledge assistant

See our AI automation services for business workflows built around your approved information and review needs. Our internal AI knowledge search checklist covers the questions to settle before a RAG pilot.

Want to discuss a pilot? Contact PlainAI Work through our website with the types of documents your team searches and a recurring question. Start with a general example without confidential company material.