How to brief an AI or systems quote properly

A good quotation starts with a good brief. If you ask for “some AI” or “a better system”, most suppliers can only guess. That usually leads to wide price ranges, missing requirements, or a proposal that solves the wrong problem.

For preparing a brief for an AI or business systems quotation, the aim is simple. Show us how the work happens now, where it breaks, what data is involved, who needs access, and what “done” must mean in practice. When we can see the real workflow, we can quote for something specific instead of vague intent.

What a supplier needs before they can quote properly

Before anyone can quote properly, we need enough detail to understand the business task, not just the desired outcome.

“Reduce admin” is a business aim. It is not yet a brief.

A usable brief normally includes these minimum points:

1. The business process being improved

Name the process in plain language. For example:

• handling new website enquiries
• checking delivery paperwork
• preparing weekly management reports
• chasing missing customer information
• publishing stock updates to the website

1. What triggers the process

Say what starts the work:

• a form submission
• an email arriving in a shared inbox
• a spreadsheet being uploaded
• a customer record changing in the CRM
• a member of staff clicking a button

1. Who does it now

List the role, not just the person:

• office administrator
• sales manager
• accounts assistant
• operations planner

1. The current steps

Write the actual sequence, even if it feels untidy. A quote based on the real sequence is far more useful than one based on an idealised version.

1. Systems already involved

Include every system touched, even if only briefly:

• website CMS
• Outlook or Gmail
• Xero or Sage
• Google Sheets or Excel
• a CRM
• a transport or stock platform
• shared folders

1. The inputs and outputs

What information comes in, and what must come out?

• input: customer name, postcode, product type, uploaded document
• output: validated record, internal task, quote request, report, approval email

1. Volume and timing

You do not need exact statistics if you do not have them, but you do need an honest sense of scale:

• a few times a week
• every morning
• seasonal spikes
• urgent same-day handling
• end-of-month backlog

1. What goes wrong now

This is often where the real project sits:

• duplicate data entry
• staff copying between systems
• missing attachments
• inconsistent naming
• approvals getting stuck
• reports taking too long to prepare
• customers receiving slow replies

1. What must not happen

This matters as much as the goal:

• no automatic sending without approval
• no overwriting finance data
• no customer record creation if key fields are missing
• no AI-generated response sent without staff review

1. What success looks like

Not “better efficiency”, but a practical result:

• staff can process an enquiry without retyping details
• missing fields are flagged before submission
• managers can approve from one screen
• the system logs who approved what and when

If you are preparing a brief for an AI or business systems quotation, this level of detail is usually enough for a serious first discussion and a more reliable quote.

AI project or simpler process fix?

Not every messy process needs AI. In many cases, standard automation or a tighter manual process is the better answer.

AI is suitable when the task involves judgement across unstructured content. For example:

• classifying incoming emails by intent
• extracting useful fields from varied documents
• drafting a response for staff review
• summarising notes from multiple sources
• spotting patterns in free-text records

Standard automation is often enough when the rules are stable and clear. For example:

• copying form data into a CRM
• creating a task when an invoice is overdue
• sending a reminder after a missing document
• routing a lead based on postcode or service type
• generating a standard report from fixed fields

A manual process should be tightened first when the problem is really operational discipline, not technology. For example:

• staff use different file names and nobody owns the process
• approvals are unclear
• source data is incomplete
• people bypass the system and keep private spreadsheets
• there is no agreed template for the information being collected

A quick test helps.

Use AI when:

• the input varies a lot
• humans currently read and interpret it
• there is enough context to judge quality
• a wrong answer can be reviewed before action

Use standard automation when:

• the rule can be written clearly
• the same conditions lead to the same result
• you want consistency and auditability

Fix the process manually first when:

• nobody agrees the current method
• key fields are optional but actually essential
• the bottleneck is ownership, not software

This distinction matters commercially. We would rather tell you a simpler workflow change is enough than force AI into a task that does not need it. If you are weighing up those options, our guide on comparing standard software with a custom internal system is a useful next read.

How to map the workflow, inputs and exceptions

The strongest briefs are not long. They are specific.

A practical way to write one is to map the process under five headings.

1. Trigger

What starts the workflow?

Examples:

• customer submits a website form
• sales email arrives with an attachment
• driver uploads proof of delivery
• manager updates a spreadsheet
• user presses “request approval”

2. Inputs

What information is available at the start?

List the fields and file types:

• customer name
• company name
• order number
• email address
• postcode
• PDF attachment
• spreadsheet row
• image upload
• free-text message

Also say where it comes from:

• website form
• Microsoft 365 mailbox
• Google Drive folder
• CRM record
• internal database

3. Main workflow

Describe the normal path in order.

For example:

1. New enquiry arrives from the website.
2. System checks whether postcode is in our service area.
3. System checks whether required fields are present.
4. If complete, create a lead record.
5. Notify the right manager based on service type.
6. Draft acknowledgement email for staff review.
7. Staff approve and send.
8. Record status changes in the CRM.

That is enough to quote from, because it tells us the sequence, the checks, and where human review sits.

4. Exceptions and edge cases

This is where many weak briefs fail. The normal route is rarely the expensive part. The difficult part is what happens when something is missing, contradictory, duplicated, or late.

State the exceptions plainly:

• if postcode is outside area, mark as out of scope and notify sales
• if attachment is unreadable, request a replacement
• if customer already exists, update the record instead of creating a new one
• if the AI confidence is low, send to manual review
• if approval is not given within one working day, escalate to a manager
• if required fields are missing, do not continue

For AI work, this is especially important. AI should support a defined workflow with permissions and human approval for consequential actions, which is consistent with the approach we use at Suffolk Web and with the practical governance most UK businesses need.

5. Outputs

What should the process produce?

Examples:

• a validated lead in the CRM
• a task assigned to operations
• a draft reply ready for approval
• a dashboard update
• a PDF summary
• an internal log entry showing action taken

If it helps, sketch the workflow as a list or simple boxes and arrows. You do not need technical notation. A plain document is fine. We also have an illustrative business workflow page that shows the level of clarity we mean.

What access, permissions and risks should be stated up front?

A quotation is only realistic if we know what systems we are expected to connect to, what level of access is possible, and what risk controls must stay in place.

Start with the systems and accounts:

• website platform and hosting
• CRM
• email platform
• accounting software
• cloud storage
• reporting tools
• internal databases
• third-party APIs

Then state the likely access level:

• read only
• create records
• update records
• send emails
• upload files
• admin access
• sandbox or test access only

Also tell us who the user roles are:

• administrator
• manager
• approver
• staff user
• external customer
• supplier or subcontractor

For each role, note what they can and cannot do.

This matters most where the workflow can trigger a consequential action. Examples include:

• sending a customer quote
• approving credit
• changing a delivery status
• creating an invoice
• publishing website content
• updating stock visible to customers

Where a human approval is required, say so explicitly. For example:

• AI may draft a reply, but staff must approve before sending
• system may prepare invoice data, but accounts must approve posting
• automation may suggest a status change, but operations manager confirms it

If personal data is involved, say what kind in broad terms:

• names and contact details
• order history
• staff records
• financial references
• special category data, if relevant

Do not guess at legal conclusions in the brief, but do flag any sensitivity. In the UK, data protection is governed by the UK GDPR and the Data Protection Act 2018, rather than the EU GDPR alone, so if a supplier is used to “EU general” wording it is worth stating that the business is operating in the UK context.

For online visibility work, state any access relevant to indexing and content control:

• who can publish pages
• who can edit titles and descriptions
• who controls robots settings
• who has access to Search Console or analytics
• whether the site has staging and live environments

Where visibility is part of the project, it helps to remember that useful, accessible content and clear links support discovery, but rankings are not guaranteed, and no special AI schema or text file is required purely for Google’s AI features, according to Google’s own guidance Google SEO Starter Guide and Google AI features documentation.

What should count as acceptance for the finished work?

A project is much easier to sign off when acceptance is defined before work starts.

Acceptance should cover five areas.

1. Functional checks

Does it do the agreed job?

Examples:

• creates a lead when a valid form is submitted
• blocks incomplete submissions
• routes the task to the correct team
• records approval history
• handles duplicate records correctly

2. Output quality

Is the content or data usable?

Examples:

• extracted fields match the source document
• drafted responses follow the approved tone
• reports show the expected totals and labels
• AI summaries include the key points and flag uncertainty where needed

For AI-assisted outputs, define the review rule. For example:

• acceptable only when staff can edit before sending
• acceptable only where low-confidence cases are routed for review

3. Reliability and exception handling

What happens when things go wrong?

Examples:

• failed API calls are logged
• users see a clear error message
• missing attachments are flagged
• partial failures do not silently lose data
• admin can retry a failed step

4. Usability and accessibility

Can real staff use it without friction?

Examples:

• clear form labels
• readable contrast
• obvious buttons
• mobile-friendly approval screens
• no unnecessary fields

These are practical quality checks, and they align with established accessibility guidance from the W3C on readable contrast, understandable navigation and clear controls W3C accessibility design tips.

5. Handover and control

What must be delivered before sign-off?

Examples:

• admin login or ownership transferred
• documented workflow
• list of connected systems
• user roles configured
• short training session completed
• backup or export method explained
• change request process agreed

If website visibility or publishing is involved, acceptance may also include:

• pages are indexable where intended
• excluded pages are excluded intentionally
• internal links are present where needed
• metadata can be edited by staff
• key pages can be found in the indexing reports

Google’s indexing documentation is useful here because it distinguishes between pages that should be indexed and pages that are correctly excluded Google Page indexing report.

A practical brief example for a quotation request

Here is a distinct example for a small UK business.

Example brief

We run a small service business in Suffolk with office staff in Ipswich and engineers working across East Anglia. We want a quotation for improving how new service enquiries are handled from website form to booked call.

Current process:

• Customer submits a website form.
• The enquiry goes to a shared mailbox.
• An administrator reads it, checks the postcode manually, copies details into a spreadsheet, and forwards it to the relevant manager.
• The manager replies manually if enough information is present.
• If details are missing, the enquiry sits in the inbox until someone chases it.

Main problems:

• Repeated copying between website, email and spreadsheet
• Delays when the right manager is not obvious
• Enquiries with missing information are not consistently followed up
• No clear record of who responded or whether the enquiry was in area

What we think we need:

• A system that captures website enquiries into one place
• Automatic postcode check against our service area
• Required-field validation
• Routing to the correct manager by service type and area
• Draft acknowledgement email prepared automatically
• Human approval before any email is sent
• Status tracking from new enquiry to booked call or closed

Inputs:

• Website form fields: name, company, phone, email, postcode, service type, message
• Optional file upload
• Existing customer list in spreadsheet format

Exceptions:

• If postcode is outside our area, mark as out of area and notify sales
• If required fields are missing, request missing details
• If the customer already exists, flag this instead of creating a duplicate
• If file upload is unreadable, notify admin for manual review

Access and permissions:

• Website admin access available
• Microsoft 365 email account available
• One manager-level approver per service line
• No automatic sending without staff approval
• No finance system access required in phase one

Acceptance:

• Valid enquiries create a record successfully
• Out-of-area enquiries are identified correctly
• Staff can approve or edit drafted acknowledgements before sending
• Status changes are visible to office staff
• Failed steps are logged clearly
• Short handover document and staff walkthrough included

That is enough for us to scope sensibly. It tells us the workflow, data, exceptions, permissions and sign-off conditions. It also leaves room for us to advise whether this is best handled with standard automation, a custom internal system, or a light AI-assisted element.

If you want more background before sending a request, see our page on custom internal AI and business systems. If you are ready to put your own brief together and ask for a quotation, use our project enquiry form.

At Suffolk Web, we keep these conversations practical. Some projects need AI. Some need a cleaner workflow, better permissions, or a simpler internal tool. That is true whether the business is in Ipswich, elsewhere in Suffolk, or across the UK.

Our wider work through Fleeta Limited includes operational and visibility projects, and the public project names readers may already know include Logivo.AI, Jagelo Haulage, Fleetalyse and Seonis. The same principle applies across all of them. A useful system starts with a clear brief, grounded in the real work.