Which Handovers Went Out Unsigned?
We could record a signature in ten different places and could not answer the one question a store manager actually asks. Storing evidence is not the same as controlling for its absence, and the gap between those two is where most operational software quietly lives.
Two weeks after shipping handover signatures, somebody asked the obvious question and we did not have an answer to it. Not "can we sign a delivery" — that worked in ten places. The question was: which deliveries went out with nobody signing? The only thing in the entire product that said anything about a missing mark was a single badge on one POS sale page. You could look up a signature you already suspected was absent. You could not find out that it was.
That is a more interesting failure than it first appears, because the feature was working exactly as designed and was still not a control.
Recording evidence and controlling for its absence
These get treated as one capability in almost every product brochure, and they are not related in the way that assumption implies.
Recording evidence
- Answers a question about one record you already have in front of you.
- Improves the record you looked at.
- Is measured by whether the mechanism works.
- Gets better as more people use it, and is silent about the people who do not.
- Is what a demo shows you.
Controlling for absence
- Answers a question about the records you did not think to open.
- Improves the process, because it names where the process is not running.
- Is measured by whether anybody looks at it on a Monday.
- Gets more useful as adoption falls, which is exactly when you need it.
- Is what you find out you needed in month four.
The asymmetry in the last row is the whole thing. A signature feature is most valuable when it is being used and hardest to evaluate when it is not — and a manager cannot distinguish "we sign everything" from "we sign nothing and nobody has mentioned it" by opening records one at a time.
Evidence you can produce on request is not a control. A control is something that tells you when the evidence is not there.
Where a signature can be missing
A handover signature is available in ten places in AWRA, across four modules. Written as one list rather than four screens, the shape of the problem becomes clear immediately: this is not an inventory question, and there was no single place in the product it could have been asked from.
| Where a mark can be taken | Module | When it is expected |
|---|---|---|
| Stock receipts and issues | Inventory | Every delivery in and every issue out |
| Stock transfer — released at source | Inventory | Once the consignment has actually left |
| Stock transfer — taken at destination | Inventory | Once it has been received or completed |
| Count sheet certified by the counter | Inventory | Once at least one line has been counted |
| Count variance certified by a reviewer | Inventory | Once the count is authorising a stock rewrite |
| Asset custody movements | Assets | An asset handed to or returned by a custodian |
| Pooled asset movements | Assets | Van stock, tool kits — part of a pool handed over |
| Till sales | POS | Optional by design; a queue is a bad place to insist |
| Till refunds | POS | Cash out with nothing back on the shelf |
| Helpdesk resolutions | Helpdesk | Once resolved or closed — field work the customer agreed was done |
The third column is not decoration. It is the reason the report is usable rather than ignored, and it took longer to get right than the queries did.
The word "unsigned" has to mean something narrow
The naive version of this report is one query per table: count the rows, count the rows with a signature, subtract. It produces a number, and the number is worthless.
Consider helpdesk tickets. Counting every ticket as an unsigned handover would mean a workspace with four hundred open tickets shows four hundred missing signatures — none of which could have been signed, because a ticket that has not been resolved has nothing to sign off. The report would open on a wall of red on day one, somebody would conclude it was broken, and they would be right.
So every source narrows itself to the rows where a mark was genuinely possible. A transfer only counts on the dispatch side once the consignment has actually left, and on the receipt side only once it has been received. A count sheet counts once at least one line has been counted. A deleted stock receipt is not outstanding evidence and drops out.
The one-sentence test for any exception report
Every row it shows must be a row where somebody could have done the thing and did not. The moment it includes rows where the thing was impossible, the number stops being an exception count and becomes a population count with a suggestive name — and the fastest way to get a report ignored is to make its first screen obviously wrong.
With that narrowing in place, "82 unsigned out of 340 eligible" means something a manager can act on: eighty-two times, somebody was standing there and nobody signed.
What you do with it on a Monday
The report shows one row per source with the eligible count, the signed count, the unsigned count and a rate, over a date window you choose, with totals underneath and CSV or PDF export. What makes it worth opening is that the rates differ from each other, and the differences are diagnostic rather than uniform.
If one site is the outlier
It is a habit, not a policy problem
Narrow the window to a fortnight and compare. A single store with a 90% unsigned rate while everywhere else runs at 15% is one storekeeper who was never shown the pad, and it is a five-minute conversation rather than a training programme.
If till refunds are the worst row
Start there, whatever the volume
This is the row we would read first in any workspace. A refund is cash leaving with nothing coming back onto the shelf, which is the shape of both a genuine return and the most common form of till fraud. A high unsigned rate here is worth more attention than a high rate anywhere else in the report.
If transfer receipts trail transfer dispatches
The receiving end is the weak end
Dispatch gets signed because somebody is loading a vehicle and the paperwork is in their hand. Receipt gets skipped because the consignment arrives during something else. That is the gap where transit shrinkage becomes nobody's to explain.
If the rate is high everywhere
Decide whether you actually want it
A uniformly high rate is not a discipline failure — it usually means signing was never asked for. That is a legitimate position. Make it a decision rather than a drift, and then this report is how you find out whether the decision stuck.
A high number is not automatically a problem
Signing is optional everywhere in AWRA, deliberately, and never blocks a movement. Nobody in a warehouse should be unable to receive a delivery because a signature could not be captured. That makes this an exception report rather than a compliance failure list, and the distinction matters more than it sounds.
Till sales are the clearest case. A queue is a bad place to insist on a signature: the cost is a slower line and an annoyed customer, and the benefit is small because a till receipt already exists. A 95% unsigned rate on till sales alongside a 5% rate on refunds is not an inconsistency to be corrected — it is a sensible operating decision showing up correctly in a report.
What the report gives you is the ability to tell the difference between that and the same figure arising because nobody has thought about it. Those look identical from the outside and are entirely different problems.
The generalisable version
This applies well beyond signatures, and the reason we are writing it down rather than just shipping the report is that we expect to catch ourselves with it again. For any evidence-capturing feature, three questions in order:
-
Can the system record it?
The part that gets built, demonstrated, and written up in release notes. Necessary, and the easiest of the three.
-
Can somebody see where it is missing, across everything, without opening records one at a time?
The part that is usually absent. Without it the feature is available rather than operating, and nobody can tell which.
-
Does the answer exclude the cases where it could not have been recorded?
The part that decides whether anyone keeps looking. Fail this and the report is technically correct and practically ignored, which is the worst of the three outcomes because it looks like coverage.
We had built the first, skipped the second, and would have got the third wrong on the first attempt if the ticket table had not made it obvious. Approvals, attachments, reason codes, GPS proof, condition notes at both ends of a custody movement — every one of those has the same three questions, and we have not audited all of them against it.
What AWRA OpsHub does today
- One report covering all ten signable handovers across inventory, assets, POS and helpdesk, with eligible, signed, unsigned and rate per source over a date window you choose.
- Eligibility narrowing per source, so an unsigned count means nobody signed when they could have rather than counting rows where a mark was impossible.
- Totals, sorting, search and CSV or PDF export, alongside the other governance reports.
- A named widest gap on the report header, so the row worth reading first is picked out for you.
What it does not do
- No per-user or per-site breakdown yet. The report is by handover type, so isolating one storekeeper or one branch means narrowing the date window and comparing, rather than reading it off a column.
- No alert when the rate crosses a threshold. You have to open the report; nothing tells you it got worse.
- No drill-through from a row into the individual unsigned records. You get the count, then you go to the module to find them.
- No trend line. Comparing two periods means running it twice.
Not ours, by choice
- It will not tell you whether a signature is genuine. It counts whether a mark exists, and a mark identifies a person only in combination with the printed name stored beside it.
- It is not a compliance failure list, and we would resist turning it into one. Signing is optional everywhere by design, and in several of these rows a low signing rate is the correct operating decision.
The four gaps in the middle column are the honest state of a first version. The one we would build next is the per-site breakdown, because "which branch" is the question every reader of this report asks second.
What is not built today can still be built for you
Anything described above as not built is a statement about what ships in the standard product today — not a limit on what AWRA OpsHub can do for your organisation. Kenya's eTIMS integration and its maintained payroll engine are both in the product because clients needed them and commissioned them; neither appeared by itself, and the same door is open for the gap you just read about. Two honest qualifications so this is worth what it claims: a handful of gaps on this blog are deliberate refusals rather than missing work — a statutory ledger we will not sign our name to, a rule that would decide a tax question for you, a clinical or member-funds record that belongs in a regulated system — and where that is true the post says so in those words rather than calling it a gap. Everything else is a scope, a timeline and a price.
The operational work, which is what most commissions actually are
An extra approval stage in a chain that does not match the standard one, a custom field set on employees or assets that only your sector needs, an expiry that has to block an order rather than send an email, a report your board asks for in a shape nothing produces, or a scanner or weighbridge feeding the goods-in door. These are the commissions we are asked for most often and the smallest ones we quote — and unlike a revenue-authority pipeline, none of them waits on a regulator.
The module-shaped gaps, which are the ones this blog admits most often
A price list with real discount authority, a customer-facing quotation that expires, a bill of materials or recipe costing, a staff advance that is issued, acquitted and chased, a member or unit ledger, a matching rule that holds a payment. Each of these is a build rather than a setting, and each has been quoted before — a bigger piece of work than a custom field, with a written spec and a date instead of a roadmap slide.
The report, document or pack nothing currently produces
The board pack in the shape your board actually asks for, a donor or funder layout, an invoice or receipt template carrying what your regulator or your customer expects, a dataset the report builder cannot reach yet. Usually the fastest thing on this list to deliver, because the data is already in the system.
Systems, rails and hardware you already run
The accounting package, CRM, online store, core banking or custom database you intend to keep — connected through our API so a fact is entered once and appears everywhere it is needed. Plus the physical edge: a scanner, a scale, a weighbridge or a till peripheral feeding the door it belongs to.
How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. Nothing here waits on a regulator or a published specification, which is why operational builds are the ones we quote fastest. Tell us the requirement that would otherwise rule us out — that is a better first conversation than a demo.
Tell us what your operation needsOur take
When you evaluate any feature that captures evidence — signatures, approvals, photographs, reason codes — ask where you would see the records that have none. If the answer is "open them and look", you are buying the ability to produce evidence on request, not a control. We shipped ten places to sign before we shipped one place to see what went unsigned, and the second one is the half that changes behaviour.
On the signatures themselves: The Squiggle Is Not The Evidence covers what a captured mark actually consists of, A Hundred Out, Ninety-Seven In covers why a stock transfer needs two of them, and The Approval That Needs No Pad covers where a signature does not belong at all. Once you are relying on a report like this, it is worth knowing that the trail underneath it is sealed against editing.
Frequently asked questions
What does the Unsigned Handovers report show?
One row per signable handover type across inventory, assets, POS and helpdesk — ten in total — with the number eligible for a signature in your chosen date window, how many were signed, how many were not, and the unsigned rate. Totals underneath, CSV and PDF export, and the widest gap named on the header.
Does it count records that could never have been signed?
No, and that is the design decision the report rests on. Each source narrows to the rows where a mark was genuinely possible: a transfer counts on the dispatch side only once the consignment has left, a count sheet only once a line has been counted, a helpdesk ticket only once it is resolved or closed. Otherwise four hundred open tickets would appear as four hundred missing signatures and the report would be noise.
Is a high unsigned rate a compliance problem?
Not necessarily. Signing is optional everywhere in AWRA by design and never blocks a movement, so this is an exception report rather than a failure list. On till sales a high rate is usually the right operating decision — a queue is a bad place to insist. What the report gives you is the ability to tell a deliberate decision apart from a drift nobody noticed.
Which row should we look at first?
Till refunds. A refund is cash going out with nothing coming back onto the shelf, which is the shape of both a genuine return and the most common form of till fraud, so an unsigned refund is worth more attention than an unsigned anything else. After that, compare transfer receipts against transfer dispatches: the receiving end is almost always the weaker one, and that is where transit shrinkage stops having an owner.
Can we see which branch or which person is not signing?
Not directly yet. The report is grouped by handover type, so isolating a site or a member of staff means narrowing the date window and comparing rather than reading it off a column. A per-site breakdown is the next thing we would build, because it is the question every reader asks second.
Will it alert us if signing stops happening?
No. You have to open the report — nothing notifies you that the rate has worsened. That is a real gap in the first version rather than a design choice, and worth knowing before you rely on it as a monitoring control.
Where does the report live?
Under Reports → Governance, alongside user activity, because it reads across four modules and does not belong to any one of them.
