Where the work actually happens.

One page that settles what counts as a real enquiry. Marketing and sales agree the test together — who you serve, and what has to be true before a name is worth a salesperson’s time. You receive that page, and a report built on it that shows three separate lines: enquiries received, enquiries that qualified, and orders won. The same batch of enquiries is followed from one line to the next, so a campaign is judged on what it produced rather than on what it collected.

The spend, the campaign source and the sales follow-up are connected, so the report rebuilds itself on a schedule instead of being assembled before each meeting. Anything the rule cannot place comes out on its own list with a name against it: an enquiry with no source, a duplicate, a name nobody has followed up. Somebody still has to deal with those, and now they arrive as a short list with owners already on it.

Once those three lines agree, AI can read what people wrote in the enquiry form and sort it: what each campaign attracted, and what buyers keep asking about. That summary arrives beside the numbers with the original wording attached, so marketing can check it before using it. Where the data is thin, it lists what is still unknown. It never moves the budget. That decision stays with a person, and the summary is what they read before making it.

One page that says what a next step is: every open deal names one owner, one action, and one date — "send the rollout schedule by Friday". You also receive a table of who owns which account, how a company in the same group maps to its parent, what happens with a personal email address, and who covers leave. The current records are tested against both, so every deal with no next step, and every account with no owner or more than one, comes back on that first pass.

The enquiry form and the sales system are connected to that table, so every enquiry lands with one recorded owner and a visible reason. An uncertain match stops in a review queue instead of going to whoever is next in line. Once the rep confirms a next step and a date, the system holds it and chases it. Anything past its date, or any open deal carrying no next step at all, appears on one list the manager reads.

Once every deal carries a next step, AI can do the reading back. It gathers what the customer asked across the thread and the meeting notes, what is still unanswered, and what the rep last promised, with the original wording attached. From the product and pricing material you have approved, it drafts the reply. The rep checks it and sends it. It can suggest the next step and the date; the rep is the one who sets them.

One current list of what was agreed: what you deliver, which revisions are included, when each piece is due, and who confirms a change. Every adjustment the two sides accept later goes onto the same list, so there is one version to check a new request against. You receive that list, and the first pass names every request already delivered that was never on it.

Before the work starts, the lead answers three questions: how much extra work this is, whether it moves the delivery date, and whether it changes the price. Some requests turn out to sit inside what was already agreed — those are recorded and closed, not charged. The rest go to the client with those three answers attached. Once it is agreed, the system updates the tasks, the owner, the dates and the budget together, and tells the people whose week just changed.

Once that list exists, AI reads the project emails and meeting notes and lists what looks new or changed against it, with the original wording attached. An example: the list has one overall analysis, and this request asks for one per department. Set it to raise too much rather than too little; a question costs a minute to answer. Where the thread is unclear it says so instead of guessing. It never decides whether something is extra work, and it never speaks to the client.

One record per item that answers four things. How much can ship today, how much is reserved and for which order, when the next purchase order is due, and what date the customer was promised. The three supplier dates are kept apart — shipped, received, cleared for shipping — because a promise to a customer is made against the last one. You receive the list of items where those four disagree today.

Every reservation is recorded against the order it is for, with how much and until when, so nothing can be promised twice. When a date changes, the system checks every order due after it against what is genuinely free, leaving other orders’ reservations alone. Anything short comes out with how much is missing, when it is expected, and whose job it is.

Supplier notices arrive as prose, and no two suppliers write them the same way. AI pulls the facts out of one — which purchase order, which item, how many, what new date — with the original message attached. Where the note says only "shipping next week", or does not say which batch it means, it lists that as unanswered rather than choosing a date. Purchasing confirms it, and the record changes then and not before. AI never decides who gets the stock: a unit reserved for a customer is a promise to a named person, and that is a fact to record, never a number to guess.

One written meaning of "resolved", signed by the support lead and by whoever holds the budget, which does not treat silence as success. One answer per question in the help centre, each marked with the products and plans it applies to, and a named person who keeps it current. And the handover conditions: which questions the AI may answer, which situations go to a person, and how a customer asks for a person and gets one.

Linking one contact to the next — by account and by person, inside the stated window — runs outside the AI tool, because a check the AI does on itself is not a check. A repeat contact about the same problem joins the original case; one about something else opens its own, and where that is unclear a person decides. On handover the case is created or updated with the summary and the whole conversation, an owner, and a reply-by date.

Answering the narrow set of questions that have exactly one written answer and involve no money, no decision about what a customer is owed, and no change to their account. That set is much narrower than the demo suggests, and its size is set by the help-centre content. The part that stops the repeating comes as it goes: it records what the customer described, what they have already tried, and what happened. When they say it is still not fixed, that is what the person receives, with the original wording attached.

One written meaning of “paid”, agreed by finance and by sales: an invoice is closed when a named payment covers it and the amounts agree. One place that holds each invoice with its customer, amount, currency, due date and what has been received against it. The remittance advice the customer sent sits beside it, rather than in somebody’s mailbox. The work starts with a list you receive: every payment sitting unmatched today, and how long each one has been waiting.

The system matches on customer, invoice number, currency and amount, and closes what agrees. A shortfall, a possible duplicate, or money it cannot place comes out on its own list with a name against it. Nothing closes on a guess: an amount still being checked stays open, and the chasing list is rebuilt only after a person confirms. The same approval path holds one more rule, on money going out. A change to a supplier’s bank details freezes the payment, and it resumes when somebody other than the person who received the request calls a number already on file and records the result.

Once the invoices and the remittance advice sit in one place, AI reads the advice — an email, a PDF, a scan — and proposes which invoices a payment covers, with the original wording attached. What it proposes is arithmetic somebody can check in a moment: these invoice numbers, this total, against this amount received. Where the wording is unclear, or a payment could cover more than one set of invoices, it says so and leaves it for a person. It closes nothing itself.

A list, by role, of what has to be ready before somebody starts: documents, equipment, accounts and the first week’s training. Each item carries an owner and a date. The day equipment must be ready, the day an account switches on and the day training begins are written separately, rather than sharing one “start date”. You receive that list, and the name against every item on it today.

Once HR confirms the start details, the system creates the tasks from that fixed list and tells each owner. When a date moves it asks the people affected what shifts with it, so nothing depends on somebody remembering to send four emails. Owners report what is actually done, and everything unfinished or overdue collects in one place. HR stops asking one at a time. The same rule runs the other way when somebody leaves. The record that decides the last day sets off a fixed, logged run through a list of its own — everything that person can reach, including what never went through the main login. Every item closes with evidence: access removed, work handed over, or an exception approved with a name against it.

The first week’s reading is assembled from documents you already have. The person receiving it is the one who cannot check it. A salesperson spots a wrong draft; somebody on day three reads a policy that changed last year and simply believes it. So AI drafts the joining notes and the first-week guide only from material the manager has approved for a new starter. Each answer is marked with the document it came from, so the reader can go and look. Where two documents disagree, or nobody can say which version is current, it stops and asks. The manager signs it before the new person sees it, and that signature is the control.

A written map of what goes where. For each connection: where the data comes from, what has to travel, when it counts as arrived, and a name against it. For this one — an enquiry from the website should be in the sales system within an agreed time, with the contact details and the request intact. The investigation discipline belongs here too. Any look at a broken connection runs on a copy, read-only, and never writes back, so that looking into it cannot alter what you are looking at.

The checking runs on its own schedule against that map, rather than waiting for something to error. It compares what the source sent with what the receiver holds, and raises the affected records when one has not arrived in time, is missing a required field, or does not match. A saved copy of every failed message, so it can be sent again. And a receiving side that can take the same message twice without making a second record, so re-sending is safe. That is engineering rather than judgement: what you need is a guarantee nothing was quietly dropped, and a tool that works on likelihood cannot make that guarantee about itself.

Ordering the search. Once the comparison has produced the list of records that differ, AI puts the useful things beside each other. Which records, which errors were logged around them, and what changed on either system that week. From that it suggests likely causes and the order worth checking them in, each suggestion pointing back to the record or log entry it came from. AI can go first here, and it is worth saying why. A wrong suggestion sends an engineer to look in the wrong place for five minutes. Nothing reaches a customer and no money moves, which is not true anywhere else it gets proposed. It also drafts the write-up afterwards: what went wrong, what was done, and what is still open. That is the part that otherwise never gets written.