Choose a situation that looks like your work. See what you would bring, follow a small worked example, and explore what your team could receive.
Example scenario · An office handling supplier invoices
Could we turn a folder of invoices into a spreadsheet we can check?
Someone currently opens each PDF, copies its reference, date and total, then checks the entries again. We could test a workflow that reads those fields, keeps the original document attached and sends unclear values to a review list.
What you bring
- A representative set of invoice PDFs or scans
- The spreadsheet columns you need filled
- Examples of difficult layouts, missing fields and duplicate invoices
What you ask
“Make one row per invoice with its reference, date and total. Flag anything you cannot read confidently, and let me check each value against the PDF.”
This invented invoice includes billing details, line items, payment terms, a due date, subtotal and tax. Trace the three requested fields among the surrounding information.
One record, with a normalized date and the invoice reference retained. Try an unclear total to see an exception stay unresolved.
Read INV-042 from the invoice reference. AC-042 is the customer account and CW-107 is the purchase order; neither belongs in this field.
Read 12 May 2026 as the invoice date and normalize it to 2026-05-12. The payment due date, 11 Jun 2026, is a different field.
Read the printed total, 480.00 CAD. The subtotal is 424.78 and tax is 55.22. Use their sum as a consistency check, while keeping the invoice for review.
Example scenario · A team answering repeat internal questions
Could staff get a useful answer from our manuals, with the source beside it?
A colleague asks how to set something up, and someone searches folders or interrupts the person who remembers. We could test a document assistant that finds the relevant passage, explains it plainly and shows where the answer came from.
What you bring
- A selected set of current manuals, policies or project notes
- Real questions staff ask repeatedly
- Rules for which documents each person may access
What you ask
“How do I set up this device? Give me the steps from the current manual and show me the page. If the instructions are missing, say so.”
The sample question is about setup. Only the manual contains the instruction needed to answer it.
The answer stays connected to the passage that supports it. Select the source link below to trace that connection.
Search all three sources for setup instructions and retrieve relevant text, not just titles.
Use the setup passage on manual page 12. Exclude the policy and notes from the answer's evidence.
Attach the manual name and page 12 so the reader can check the instruction.
Example scenario · A team sharing a service inbox
Could incoming requests reach the right reviewer with less manual sorting?
Setup problems, billing questions and vague requests arrive in the same queue. We could test a workflow that reads the message, identifies the topic and suggests a team, while keeping uncertain cases in a visible review queue.
What you bring
- A representative sample of past requests
- Your teams, queue names and routing rules
- Examples that were misrouted or needed clarification
What you ask
“Separate setup issues from billing questions. Keep the original message and flag anything that needs clarification before it is assigned.”
Three invented messages show a clear support request, a clear billing request and a case with too little information.
Two requests have proposed destinations. The third remains visible for clarification, with no automatic reply sent.
Ticket #01 asks for setup help, so suggest the technical support queue.
Ticket #02 mentions a bill, so suggest billing without interpreting the account details.
Ticket #03 has no topic. Keep it for human review instead of choosing a queue at random.
Example scenario · A team preparing meeting follow-ups
Could our rough notes become a brief people can act on?
After a meeting, someone has to separate what was agreed from ideas, tasks and unanswered questions. We could test a drafting workflow that organizes the notes into your preferred format and leaves missing owners or dates explicit.
What you bring
- Meeting notes or project updates
- A sample of the brief your team prefers
- Any confirmed owners, dates and decisions
What you ask
“Draft the project update: what we decided, what happens next and what still needs an answer. Do not invent a reviewer or turn a suggestion into an agreement.”
The notes contain one agreed decision, one action and one unresolved question. The draft should keep those distinctions.
This is a draft for a person to edit. The unanswered question is part of the output, not a gap to fill by guessing.
The trial next week is marked agreed, so carry it into the decision section.
Preparing sample data is work to do, so make it an action without inventing an owner.
The demo reviewer is unresolved. Preserve it as an open question for the meeting owner.
Example scenario · A team reviewing revised specifications
Could we see which changes in a revised document need our attention?
A new proposal or specification arrives, but the important change may be a quantity, a date or a sentence buried on page two. We could test a comparison that lines up the versions and produces a change list linked to the original passages.
What you bring
- The original and revised documents
- Sections or fields that matter to your review
- Known examples of subtle changes and harmless formatting differences
What you ask
“Compare these two specifications. Show the old and new quantities, dates and scope wording, and point me to each change in the documents.”
The sample aligns three corresponding parts of two specifications. Layout changes alone should not count as substantive edits.
The change list helps a reviewer decide where to look. The linked wording is needed to judge what the scope change means.
Align the quantity fields: the original says 20 units and the revision says 30, a difference of 10.
Compare 12 May with 19 May: the revised deadline is seven days later.
Locate the revised scope on page 2 and send the reviewer to the wording itself.
Example scenario · A team consolidating product spreadsheets
Could we clean up an import without losing the differences that matter?
Rows copied from different files may use inconsistent names, repeat an ID or leave a field blank. We could test a workflow that proposes consistent labels and groups suspicious records, with the original values kept for review.
What you bring
- A representative spreadsheet or CSV export
- The agreed column meanings and naming rules
- Examples of duplicates and similar records that must stay separate
What you ask
“Make product labels consistent, flag repeated IDs and show missing values. Give me proposed edits to approve before any records are merged.”
The example contains a difference in letter case, a repeated ID and a blank label. Each needs a different kind of treatment.
A tidy-looking file is not enough: the reviewer also needs the proposed changes and the records that still need a decision.
Compare Widget A with widget a and propose a shared label format under an agreed naming rule.
Both rows use ID 042. Flag the pair for review; the shared ID does not justify an automatic merge.
ID 044 has no label. Leave it unresolved and ask the data owner rather than inventing a name.
Example scenario · A team receiving loosely defined project requests
Could a vague request become a handoff the next person can use?
“Can we demo this next week?” leaves a team to discover the missing brief, data and reviewer. We could test a workflow that reads the request, applies your preparation checklist and returns the next steps alongside the decisions still needed.
What you bring
- The original request and relevant project notes
- Your usual preparation checklist
- Known constraints, deadlines and approval roles
What you ask
“Turn this demo request into a preparation checklist. Tell me what we need to collect, what scope to agree and which missing decisions block the handoff.”
The sample request gives a deadline but leaves preparation and review decisions unresolved. A useful handoff makes those gaps visible.
The checklist is ready to discuss, not automatically assigned. A person still confirms scope, ownership and review.
The demo needs a brief and sample data. Turn those requirements into explicit items to collect.
Next week is a deadline, not a definition of the demo. Ask the team to agree what it must show.
No reviewer is named. Keep that decision open and visible in the handoff.
Example scenario · A team keeping track of chosen tools or suppliers
Could we get a short digest of relevant changes instead of checking every page?
Someone repeatedly visits release notes and documentation to see whether anything affects the team's work. We could test a workflow that compares selected sources with the last check, filters for agreed topics and drafts a digest with links.
What you bring
- The specific public pages or feeds to monitor
- Topics and products your team cares about
- Examples of useful updates and changes you would ignore
What you ask
“Check these release notes and setup guides. Summarize changes that affect our chosen tools, include the original links and leave unchanged sources out of the digest.”
Three invented source checks produce two updates. These are sample references; this demonstration is not connected to live feeds.
The digest contains the two relevant changes. The unchanged source appears only to explain the filtering in this demonstration.
Source A contains a relevant release. Keep its change summary and the original reference.
Source B has no relevant change. Record the check but omit it from the update digest.
Source C has a revised setup guide. Include the change with its source reference.
Example scenario · Restaurant owners and managers
Which dishes sell best at each service—and what should we test next?
Bring together point-of-sale item sales, covers, dates and service times to compare what guests order at lunch, dinner and across the week. AI can help interpret the records and explain possible patterns, while visible calculations keep the comparisons checkable.
What you bring
- POS export: dish, quantity, price, date and time
- Guest counts (covers) by service, with dates and opening hours
- Menu changes, promotions and unavailable dishes
What you ask
“Show me which dishes are more popular at dinner, whether that holds across several weeks, and what we could try next.”
This worked example contains one lunch and one dinner; a broader assessment would compare many services and their context.
These two rates would be one finding in a larger report, with source records and a proposed test rather than an automatic menu decision.
Lunch: 11 pasta orders ÷ 50 covers × 100 = 22 per 100 covers.
Dinner: 18 pasta orders ÷ 48 covers × 100 = 37.5 per 100 covers.
Compare the rates, then check dates, availability and promotions before interpreting the difference.
Example scenario · Shop owners and stock buyers
Which products could run out before the next delivery?
Match recent item sales with available stock, incoming orders and supplier lead times to build a list of products needing attention. AI can help reconcile descriptions and explain exceptions, while stock calculations show why each item appears on the list.
What you bring
- Item sales and available stock by product code
- Open purchase orders and expected arrival dates
- Supplier lead times, pack sizes and known promotions
What you ask
“Show me what might run out before delivery, what is already on order, and which items I should review first.”
This worked example shows one product with five units, sales of two per day and a four-day lead time; incoming orders are not shown.
The calculation would become one line in a broader reorder review list, with incoming stock and demand assumptions checked before an order.
Five units available ÷ two sold per day = 2.5 days of stock if that rate continues.
A four-day delivery time exceeds stock cover by 1.5 days; four days of demand would use eight units.
Check incoming orders and changing demand before treating the possible three-unit shortfall as a reorder quantity.
Example scenario · Service business owners and schedulers
Which appointment types need more time—and where would a buffer help?
Compare scheduled slots with actual start and finish times for the same service type to separate late starts from jobs that overrun. AI can help group records and explain recurring exceptions, while the duration comparisons remain visible.
What you bring
- Bookings: service type, scheduled start and finish
- Actual start and finish times, including cancellations
- Notes on job complexity, travel and unusual delays
What you ask
“Show me which services regularly overrun their slots and where a small scheduling change would be worth testing.”
This worked example contains three jobs booked for 60 minutes; it suggests a question to test, not a reliable duration for every appointment.
This comparison would sit within a larger scheduling report that separates long jobs, late starts and unusual circumstances before proposing a trial.
Compare three jobs of the same type: actual durations of 70, 75 and 80 minutes against a 60-minute slot.
The middle observed duration is 75 minutes, which is 15 minutes longer than the booked slot.
Treat a 15-minute buffer as a trial; measure subsequent delays and unused capacity before expanding it.
Example scenario · Project managers and estimating teams
Which parts of our jobs run over estimate—and what should we investigate?
Match job estimates, logged hours, material records and approved scope changes to compare planned and actual work by project stage. AI can help organize explanations and locate relevant notes, while the report keeps measured differences separate from unproven causes.
What you bring
- Estimates by job ID and work stage
- Timesheets and material records linked to the same jobs
- Approved scope changes and project notes
What you ask
“Show me where this job exceeded its estimate, which changes were approved, and what still needs an explanation.”
This worked example compares 40 planned hours with 52 logged hours; material costs and scope history are outside the displayed sample.
The hours variance would be one part of a broader job review; it measures a difference without claiming its cost or cause.
Match the same job: 52 logged hours minus 40 planned hours equals 12 additional hours.
Divide the 12 additional hours by the 40-hour plan to calculate a 30% labour-hours variance.
Check stage records and approved scope changes before attributing the extra hours to an estimating problem.