Regisseur · Product Walkthrough
What happens when a document is missing?
Three real, end-to-end cases: one where everything arrives on time, one where a document is missing and the vendor replies, and one where the vendor never replies at all — and the platform hands it to a person instead of guessing or giving up silently.
3
Real case scenarios shown
1
Real vendor reply, real upload, real auto-resume
1
Real, automatic handoff to a person when nobody replies
0
Fabricated screens
114
Screens captured live
About this walkthrough
Every screen below is a real screenshot from four automated, end-to-end runs of Regisseur against a real, working deployment — not a mock-up, not staged data. Company and person names shown (Fabrikam Energy, Contoso Field Services, Dana Whitfield, Priya Chandrasekaran, Owen Farrell) are fictional demo identities. During the very first live run of the "vendor replies" story in Part 2, a real integration bug was found — the vendor's upload link didn't work the first time it was actually tried by a real person — and it was fixed on the spot before the second run, the one shown here, which completed cleanly end to end. That is exactly the kind of thing running the real product, instead of a rehearsed demo, is meant to catch.
Part 4 was captured in its own separate run. Two things are worth saying plainly about it. The emails in this walkthrough go to a mailbox we own, standing in for the vendor contact's real inbox — the sending, the delivery and the reply are genuine, the mailbox is ours. And the vendor's reply is a real email with a real attachment, sent and received over the real mail system, but its "from" name is our own mailbox rather than the vendor's, because the mail platform will not let an application send as an arbitrary person; the reply is matched by the unique address it was sent to, never by who it claims to be from. One more: the vendor company shown against the contact was already known to the system before this case started, so that link is one the platform kept rather than one it created here — what is genuinely new in this run is the contact being placed on this case, which nobody did by hand.
About the signature at the end of Part 4: two separate facts have to be true before the platform will ask the vendor to sign anything, and they come from two different places. The vendor's own supplier record says who may accept an adjustment on their behalf, and that person is put on the case unable to sign. The signed agreement between the two companies — fetched from the vendor's own document library — is what says they may, and only that turns the ability on. Nobody vouches for themselves at any point. The invitation carrying the signing link is a real email, redirected like every other message in this walkthrough to a mailbox we own rather than the fictional signatory's. And the signature itself is applied through the signing service's own interface rather than by drawing on screen, because these runs are automated; the signed document that comes back is the real one the signing service produced.
The Audit tab shows the rules that decided, each with its versioned rule key; the export carries them as determination rows.
Part 5 shows the platform declining to do something, which is worth saying plainly because it is easy to mistake for a failure. The supplier in that part really is set up correctly in every other respect; what is genuinely absent from their record is anyone named as authorised to accept an adjustment. The platform reads that absence, writes down what is missing, sends nothing out for signature, and hands the case to a person — rather than choosing a plausible-looking contact or skipping the acknowledgement without saying so. Both parts are in this walkthrough on purpose: a system that could not tell them apart would be worth less, not more.
Part 1 — The Straightforward Case
Everything the platform needs arrives up front. It checks, finds nothing missing, and moves straight through — no one has to chase anything down.
Getting Started
A case is created and goes live
A new case begins from a pre-built process template — the same starting point every case in this walkthrough uses.
Before anything happens, the platform shows exactly who is responsible for the one step that needs a person — no surprises about who owns what.
A final confirmation shows the full shape of the process — how many steps, how many need a person — before the case goes live.
The moment the case activates, the platform's own visual map of every step lights up, ready to track progress end to end.
Everything Arrives Together
The invoice and its supporting document, both on hand from the start
The invoice document is uploaded and automatically read.
The supporting field document is attached at the same time, before the first step is even marked done.
Once the first, human step is marked complete, everything downstream picks up on its own — no one has to kick off the next step by hand.
Straight Through, Automatically
Nothing is missing, so nothing needs to be asked for
The platform reads the invoice and pulls out the details it needs.
The platform checks the vendor and purchase-order details against the company's own records.
Because the supporting document was already there, the platform routes straight past the follow-up step entirely — visible right on its own process map.
Nothing Left Waiting
Because nothing was missing, there is nothing to chase
"No obligations recorded on this case." Because nothing was missing, no request was ever sent, and nothing is ever left waiting on anyone.
Part 2 — When Something's Missing, and the Vendor Replies
One document is missing at the start. The platform drafts a request, a person reviews and approves it, a real email goes out, the vendor's contact opens it and uploads what was asked for through a secure link — and the case continues on its own, no one has to notice the reply and restart anything. From there it carries straight through review, paperwork, and a system-of-record update, to a clean close.
A Different Case Begins
The same process, a different starting point
The case owner's own dashboard, before this case exists — real, everyday working content.
The same process template as Part 1 — this time, the story goes a different way.
The one human-owned step is assigned before the case goes live.
The case is given a named owner, visible on the case itself.
One Document Is Missing
The invoice arrives; its supporting document does not — yet
The invoice is uploaded — but this time, its supporting document isn't attached yet. That gap is the whole story of this case.
The Platform Notices, and Reaches Out
An automatic check catches the gap and prepares to ask for what's missing
"No confirmed external parties on this case yet." Nobody outside the company is on the record for this case — yet.
This time the platform's own check finds the supporting document missing, and routes the case down a different path — toward asking the vendor for it.
A Person Reviews Before Anything Is Sent
A drafted request, reviewed and approved by a real person before it goes out
The platform drafts the exact email it wants to send, explaining clearly why it's asking and what it needs, and holds it for a person to review before anything goes out. Nothing is ever sent without that review.
The case owner reads the drafted request and chooses to send it exactly as written.
The approval is submitted, and the real send follows immediately.
The case's own communications record shows the request going out — a genuine, timestamped event, not a placeholder.
Now We're Waiting — and Everyone Can See It
The outstanding request is visible, front and center, the moment it goes out
The moment the request goes out, it appears as an open item on the case — what's being waited on, and the built-in follow-up schedule if nothing comes back.
The same outstanding request also shows up on a workspace-wide worklist — anyone checking their own queue can see it, not just someone who happens to open this specific case.
The case is now waiting on someone outside the company to act — a real person has to open a real email and respond.
The Reply Arrives — and the Case Picks Itself Back Up
A real reply, a real upload, and the case continues on its own
The vendor's contact opens the email and uploads the missing document through a secure link made just for them. The moment it lands, the case's own map shows it move on to the next step — nobody had to notice the reply and restart anything.
The outstanding request updates itself to "Satisfied" the instant the document arrives — not because someone remembered to check and close it out by hand.
The vendor contact added earlier in the case stays on the record after everything else moves forward.
The case's communications history shows both sides: the original request, and confirmation that the link was opened.
A full, unfiltered timeline of the case — including the moment it picked itself back up — available at any time.
Back on Track, With No One Pushing It
The very next step is already underway — untouched by a human
With no further action from anyone, the case has already reached its next step — the real work of applying the contract terms picks up immediately.
A Second Set of Eyes, When the Stakes Are High Enough
Above a certain amount, a person reviews before anything is finalized
Once the numbers cross a set threshold, the platform automatically routes the case to a qualified reviewer rather than deciding on its own.
A Real Person Makes the Call
The reviewer reads the numbers, and decides
The platform lays out its own recommendation — the contract terms applied to the actual numbers on the invoice — and waits for a real person's decision. Nothing is finalized without it.
The reviewer reads the recommendation, approves the adjustment, and puts their name on the record — the same name that will appear on the paperwork this decision produces.
"Input submitted — the agent will resume with your input." The decision is recorded, and the case continues on its own from there.
The Paperwork Writes Itself, and the Books Get Updated
A formal document is generated, and the vendor's own record is updated to match
A formal adjustment memo is generated automatically from the reviewer's own decision — a real, downloadable document, not a summary or a placeholder.
Done — for Real
Every step of this case, completed
The case's own status reads Complete, and its process map shows every step so far settled — from the very first document, through the reviewer's decision, to this point.
The Full Record
A complete, unfiltered history of everything that happened on this case
"No coordinator inquiries for this case. No open escalations." Because this vendor replied and every review happened promptly, there is nothing left outstanding — a useful contrast with what you'll see in Part 3.
One continuous, unfiltered record covering the entire case — from the first document received to the very last step closed.
Looking back at the full case, exactly one outbound message was ever needed — the original request. Everything after that (the review, the paperwork, the system update) happened without needing to contact anyone again.
Every case carries its own complete, timestamped audit trail — available on demand, ready to export.
Expanded, the audit trail shows real counts — every event and every document tied to this case, downloadable as a complete record.
Part 3 — When Nobody Replies
The identical process, except this time the vendor never responds. The platform follows up automatically on a fixed schedule, and once those attempts are used up, it doesn't keep trying on its own — it hands the situation to a person, clearly and on the record, across every place that person would look.
The Same Process, a Different Outcome Ahead
Same steps, same checks — this time, the vendor won't reply
The same everyday dashboard, before a new case with a very different outcome begins.
The same setup as before — the one human-owned step is assigned before the case goes live.
A named owner is assigned to this case too.
The Same Missing Document
This time, nobody ever supplies it
The invoice arrives without its supporting document, exactly like Part 2 — except this time, nobody ever supplies it.
The Same Request Goes Out
Reviewed and approved the same way — a real request, sent
The platform drafts the identical kind of request as before, and holds it for review — the process treats every case the same way, whether or not the vendor is about to reply.
The case owner reviews and approves the request exactly as before.
The request goes out, recorded on the case exactly the same way as in Part 2.
Waiting Begins
The outstanding request is on the record, the same as before
The outstanding request appears immediately, with its built-in follow-up schedule — the same starting point as Part 2's story. This time, no reply ever comes.
Following Up, On a Schedule
The platform checks in periodically, on its own schedule, with nothing from a human required
The platform checks in on its own, on a fixed schedule, without anyone needing to remember. After several attempts with no response, the request is now marked overdue on the case record.
When Follow-Ups Run Out, a Person Takes Over
After the built-in follow-up attempts are exhausted, it's handed to a person — not sent again automatically
Once the built-in follow-up attempts run out, the platform does not keep re-sending on its own. It hands the situation to a person, with a clear, plain-language explanation of exactly what happened and what's needed.
The same situation shows up directly in the team's own notifications — not buried on a single case page, but somewhere a person checking their own inbox will actually see it.
The same information shows up consistently on a second, independent screen too — the team sees the same clear picture no matter which view they check.
Left Honestly Open
No invented resolution — the case stays exactly where the facts leave it
The case's process map shows exactly where things stand: everything up to this point is done, and the step waiting on the vendor is still open. Nothing is invented or force-completed — if the vendor replies later, the case can still pick up from exactly here.
Part 4 — The Vendor Just Replies
The same missing document as Part 2, answered the way an accounts-payable desk actually answers: by replying to the email with the document attached. Two things are different from Part 2, and both remove a step somebody used to have to do. The vendor's contact is put on the case record by the platform itself, read from the company's own vendor master — nobody types them in. And the request is addressed to that contact as a relationship rather than to a bare email address, so the follow-up, the audit trail and the outstanding-request list all know who is being waited on. The vendor never opens a portal, never creates a login, and never sees anything but an ordinary email thread.
Part 4, by the numbers
| Decisions a person made | 2 |
|---|---|
| Vendor contacts entered by hand | 0 |
| Times the vendor had to open a portal | 0 |
| Automatic follow-ups needed | 0 |
| Signatures collected from the vendor | 1 |
| Signatories the platform put on the case itself | 1 |
| Signatories entered by hand | 0 |
| Total time a person spent on it | 2.9 seconds |
| Start to finish | 346.9 seconds nearly all of it waiting — for the vendor to reply, and for the next scheduled check of the mailbox — rather than working; the line above is the time a person actually spent |
Two decisions. Nobody bound the vendor by hand, and the vendor never opened a portal — and the vendor signed the adjustment without anyone setting up the signatory.
Every figure is read out of this run's own record when the report is built — none of it is typed in by hand.
The Same Gap, Answered a Different Way
The invoice arrives without its supporting document — this time the vendor simply replies
The case owner's own dashboard, before this case exists.
The one human-owned step is assigned before the case goes live.
The platform's own map of every step, ready to track this case end to end.
One Document Is Missing, Again
The same starting point as Part 2
The invoice is uploaded without its supporting field document — the same gap as Part 2, and the same starting point for a very different way of closing it.
The one human step is marked complete, and everything downstream starts on its own.
The Vendor's Contact Puts Themselves on the Record
Nobody types the vendor's contact in by hand — the platform adds them from the company's own vendor records
The platform looks the vendor up in the company's own vendor master, confirms the account is active and the purchase order is open, and reads the accounts-payable contact from that record — not from the invoice a supplier sent in.
The vendor's accounts-payable contact now appears as a party to this case, added by the platform from the company's own vendor record. In Part 2 this screen stayed empty until a person filled it in by hand. Their employer was already known to the workspace before this case began, so the company name shown here is a pre-existing link the platform kept rather than something it created.
Two people are now on this case, both added by the platform from the vendor's own supplier record and neither typed in by anyone: the accounts-payable contact, and the person the vendor names as authorised to accept an adjustment. The second one's ability to sign shows as declared but inactive. Being named in a supplier file makes you contactable; it does not, on its own, make you able to commit the company.
The automatic completeness check finds the supporting document missing and routes the case toward asking the vendor for it.
The Request Goes to a Relationship, Not an Address
Reviewed and approved by a person, exactly as before
The platform drafts the exact email it wants to send and holds it for review. It is addressed to the vendor contact recorded on this case a moment ago, so the request, the follow-up schedule and the audit trail all know precisely who is being waited on.
The case owner reads the drafted request and chooses to send it exactly as written. Nothing goes out before this.
The case's own communications record shows the request going out — a genuine, timestamped event.
The moment the request goes out it appears as an open item on the case, tied to the vendor contact it was sent to, with its built-in follow-up schedule if nothing comes back.
Opening the Mailbox — Deliberately, and Only One at a Time
Reading a mailbox is switched on for a bounded window, and the platform refuses to open a second one
Watching an inbox for replies is not left permanently on. An operator opens a bounded window, the platform enforces it, and it closes itself when the time is up.
Asked to open a second reading window on the same mailbox, the platform declines and explains why — two readers on one inbox would race each other, and whichever lost would mark a reply read without ever delivering it.
The Vendor Just Replies, Document Attached
The reply itself is the answer — the attachment lands on the case and it carries on by itself
The vendor simply replies to the email with the field document attached. The attachment lands on the case as that step's own evidence, and the step completes — no portal, no login, no separate upload page.
The outstanding request updates itself the instant the reply arrives — not because somebody remembered to check the inbox and close it out.
The case's own map shows it moving on to the next step. Nobody noticed the reply and restarted anything.
The Rest of the Case, Unchanged
Contract terms applied, reviewer decision, paperwork, and the vendor's own record updated
With no further action from anyone, the case has already reached the step that pulls up the governing contract.
The same person, moments later: the ability to sign is now live. What changed is that the signed agreement between the two companies has been pulled from the vendor's own document library onto this case, and the platform recorded that as the reason. Nobody switched this on by hand, and nobody vouched for themselves.
Once the numbers cross a set threshold, the case routes automatically to a qualified reviewer rather than being decided on its own.
The platform lays out the contract terms applied to the actual numbers, and waits for a real person's decision.
The platform recommended adjusting the invoice to what the contract entitles. Here the examiner tries the opposite — letting the vendor's full amount stand — without saying why.
Rejecting the recommended adjustment is an override, and an override without a stated reason is not a decision the platform will accept. The step stays open until the examiner explains, and nothing is written in the meantime.
The reviewer approves the adjustment and puts their name on the record — the same name that appears on the paperwork this decision produces.
The decision is recorded and the case continues on its own from there.
A formal adjustment memo is generated automatically from the reviewer's own decision.
With the authority established, the case takes the signature route. The alternative route — the one that puts the case in front of a person instead — is right there on the map, unused. Part 5 is the case that takes it.
The step sits in a state of its own — waiting for signature. The case does not proceed, nothing is assumed on the vendor's behalf, and anyone looking at the case can see exactly what it is waiting for.
The vendor's signed acknowledgement is attached to the step that asked for it, alongside a note saying which signing request it came back from. Not a status flag saying a signature happened: the executed document itself, on the case, where anyone reviewing the file later will find it.
Done — for Real
Every step of this case, completed
The case's status reads Complete, and its map shows every step settled — from the first document through to the vendor's own record being updated.
The Full Record
The case's own history, and its audit trail filtered to the decisions people made
One continuous, unfiltered record of the whole case — including the moment the vendor's reply satisfied what was outstanding and the case carried on by itself.
The same audit trail, filtered to the moments a human actually decided something — the shortest honest answer to "who approved this?"
Expanded, the audit trail shows real counts — every event and document tied to this case, downloadable as a complete record.
On a single screen, newest first: the case's closing steps (the vendor's signature and the update written back to their own system of record), the two moments a real person made a decision, and the platform's own rule-based findings sitting right alongside them. One finding worked out what was actually owed under the contract — citing the exact clause it applied — and sent the case to a person because the amount went over the threshold. The other found that the signed agreement was on file, which is what allowed the signer's authority to switch on. Each finding names the exact rule behind it and which version of that rule ran, so "on what basis?" gets as clear an answer here as "who approved this?"
Filtered down to just the rule-based findings, with nothing else in the way: three of them for this case — the check that first noticed the supporting document was missing, the calculation that worked out what was owed, and the check that activated the signer's authority once the signed agreement was on file. Each one names its own rule and the exact version that ran.
Above the tabs, the platform writes a short brief of where this case stands — from the case's own facts, step states and open requests, never from the documents or messages themselves — and labels when it was generated. A reader has context before the ledger.
The request that went out and the vendor's reply that came back, each a real timestamped message the case can open.
The message itself: who it came from, when, what it said, and what the platform did with it. Addresses are masked on screen; the text is shown as it arrived, and the platform says so.
Part 5 — The Vendor Who Has Nobody Able to Sign
The same process again, with a different supplier — and everything works right up to the last step. The supplier is active, the purchase order is open, both documents arrive, the contract terms are applied and a reviewer approves the adjustment. Then the platform goes to ask the supplier to acknowledge it, and finds that the supplier's own records name nobody authorised to accept an adjustment on their behalf. That is an ordinary thing to find in a real supplier file, not a fault. What matters is what happens next: the platform does not pick somebody who looks close enough, and it does not quietly skip the acknowledgement. It writes down precisely what is missing, sends nothing for signature, and puts the case in front of a person to decide. Being able to tell this case apart from the previous one is the point.
Part 5, by the numbers
| Decisions a person made | 2 |
|---|---|
| Documents sent out for signature | 0 |
| Start to finish | 138.8 seconds |
Nothing was sent for signature, nothing was guessed, and a person was given the decision.
Every figure is read out of this run's own record when the report is built — none of it is typed in by hand.
The Same Process, a Different Supplier
Nothing is configured differently — only the supplier is
Nothing about this case is set up differently from the last one. The only difference is which supplier the invoice came from.
The steps a person owns are assigned before the case goes live — including the review step this case will turn out to need.
Nothing Is Missing This Time
Both documents arrive together, so nothing later can be mistaken for an ordinary missing-document story
The invoice and its supporting field document are supplied together at the start. That is deliberate: it means nothing that happens later in this case can be mistaken for the ordinary "something is missing" story of Part 2.
The one human step is marked complete, and everything downstream starts on its own.
The Supplier Checks Out — and Names Nobody Who Can Sign
An active supplier with a real contact for questions, and an empty space where an authorised signatory would be
An automated step reads the company's supplier records for this vendor and completes. What it found is on the next screen, where it can actually be seen.
The supplier's file gives a real person to correspond with, and names nobody authorised to accept an adjustment. So the case carries exactly one contact and no signatory — not a placeholder, not an "unknown" person, not an error. The absence is recorded as the fact it is, and every later step reads it that way.
The Adjustment Is Still Worked Out
The agreement is read and the figures computed exactly as before — what cannot be done is ask the supplier to accept them
The adjustment is larger than the amount the platform is configured to settle on its own, so it goes to a reviewer rather than straight to paperwork.
A Reviewer Approves It
Above the threshold the platform settles on its own, so a person decides — and a real memo is produced
The contract terms applied to this invoice's real figures, laid out for the person who has to decide: what was billed, what the agreement allows, and the difference between them.
A named person makes the call and their name goes on the record — and onto the paperwork the decision produces.
The memo is generated from the reviewer's own decision and can be downloaded. This is the document the supplier would normally be asked to counter-sign — which is exactly why what happens next matters.
It Goes to a Person Instead of a Signature
Nothing is sent out to be signed, and the case is put in front of the reviewer who can decide what to do
The platform reaches the point of asking the supplier to acknowledge the adjustment, finds nobody authorised to do so, and takes the other route: to a person. The signature step is left untouched, and the supplier's record cannot be updated yet.
A reviewer is asked a single, plain question — how should this adjustment be disposed, given that the supplier names nobody who can accept it — and asked to confirm they have read the platform's own recorded explanation before answering.
Above the form the reviewer has to fill in, the case shows exactly what the platform found, in the platform's own words: no one on this case is on record as authorised to accept an adjustment on the supplier's behalf, so there is no one to ask for a signature. It's the same sentence the platform recorded when it made that finding — not new wording written for this screen.
Filtered to the platform's own rule-based findings, this case's trail shows the calculation that worked out the adjustment — and nothing else. There is no finding here, or anywhere in the record, saying anyone's signing authority was ever activated, because the supplier never named a person who could hold it. On this case, the absence itself is the accurate record.
The reviewer records the decision to dispose the adjustment without a counter-signature. That decision, and not a silent skip, is what lets the case continue.
The supplier's own record is updated only once somebody has either signed for the supplier or decided, on the record, to proceed without them. Before this step it was held; after it, it runs.
Decided, Recorded, Closed
The supplier's own record is updated behind the human decision, and the case finishes
Every step of this case is settled, and the signature step was never started at all. Two decisions: approving the adjustment, and disposing it without a counter-signature. Nobody was asked to sign, because there was nobody who could.
The Full Record
The case's own history, and the two decisions it actually needed
One continuous record from the invoice arriving to the case closing — with the step that was skipped, and why, part of the same story.
Filtered to the moments a person decided something: the approval of the adjustment, and the decision to dispose it without the supplier's signature.
The complete event and document trail for this case, downloadable as a record.
