The Engineer Left and the Ticket Closed
On a desk ticket the requester is the check: if it is not fixed, they will say so in the thread. In the field the engineer drives away, the ticket closes, and “resolved” becomes one person’s word. Why the customer’s mark has to be taken while they are still standing there, why a failed drawing is refused rather than quietly dropped, and why reopening the ticket withdraws it.
The call-out was for a card reader on a branch office’s side door. The engineer arrived at ten, replaced the reader, badged in and out twice with the office manager watching, packed up and left. In the van, before the next job, he marked the ticket resolved. Three weeks later the branch disputes the call-out charge: the door, they say, has never worked properly since. The office manager who watched the test has moved to another site. The ticket says resolved, with a timestamp, and the only person whose word it records is the engineer’s.
Nobody in that story did anything wrong. The engineer tested the work. The office manager saw it work. The ticket was closed promptly, which is what every service level target asks for. And yet the organization now has a disagreement it cannot settle, because the one moment when the customer could have agreed the job was done came and went without anyone writing that agreement down.
This is a field problem, not a helpdesk problem in general, and it is worth being precise about why.
Two kinds of resolved
A ticket system treats every resolution the same way: someone with the right permission changes the status, and the time is recorded. Whether that is enough depends entirely on where the work happened.
A desk ticket
- The requester is on the other end of the thread and sees the resolution as soon as it is recorded.
- If the password reset did not work, they reply within the hour and the ticket comes back.
- Silence after a resolution is a reasonably strong signal that the fix held.
- The evidence that the work was done is the thread itself.
A field job
- The person who saw the work is a site contact, a receptionist or a shift supervisor who may never open the ticket.
- The engineer often resolves it later, from the van or the next site.
- Silence means nothing: the contact may not know there is a ticket to reply to.
- The evidence that the work was done left in the engineer’s van.
On the desk, the requester is the control. They are the person most motivated to object, and they are in a position to. In the field, the person best placed to confirm the work is present for perhaps fifteen minutes and then out of reach. Asking them afterwards, by email, a week later, about a job they half remember, produces either no answer or a guess.
Once the engineer drives away, “resolved” is one person’s word. The customer’s agreement is only available while they are still standing there.
What the sign-off actually records
AWRA’s helpdesk takes the requester’s sign-off on a finished ticket. It is three things written onto the ticket, plus one note in its history:
| What is stored | Where it shows | Why it is there |
|---|---|---|
| The printed name of the person signing | The sign-off card on the ticket, the mobile app, the requester’s own view | A drawn mark identifies nobody on its own; the name does |
| The time it was taken | Beside the name, to the minute | It places the agreement on the day of the visit, not three weeks later |
| A hand-drawn signature, when one is taken | An image on the card, openable full size | It shows the person put their own hand to it |
| An internal note in the ticket thread | The thread, authored by the agent who took it | The thread is where a ticket’s history is read, so the sign-off and who collected it sit there too |
The order in that table is deliberate. The argument for why a printed name and a time do more work than the drawing is made at length in The Squiggle Is Not the Evidence, and it applies here unchanged: nobody can read a signature, which is close to the definition of one. So the helpdesk accepts a typed name on its own as a complete sign-off. The pad failed, the tablet is old, the customer’s hands are full: the engineer still writes down who accepted the work, and that is a valid record.
The note in the thread is internal on purpose. It is a record for the team, and posting it publicly would send the requester an email about their own signature.
When the pad appears, and when it does not
A sign-off says the work was finished, so it can only be taken once the ticket is resolved or closed. A signature collected on an open ticket would be a signature for nothing. A cancelled ticket cannot be signed either: nobody worked on it, so there is no job to sign for.
-
Resolve and sign in one action
The common case. On the ticket, the engineer picks Resolved or Closed, the customer signs on the same form, and both are saved together. The status is written first, so the ticket is already finished by the time the signature rule is checked. The mobile app does the same in a single request.
-
Or sign a moment later
The engineer who closed the job on the way out and catches the customer at the door opens the resolved ticket and finds a sign-off card waiting. Same rule, same checks.
-
Signed once
After that the card is locked. It shows who signed and when, and a single line telling the agent to reopen the ticket if the work was not finished. There is no replace button, for anyone.
Two small decisions sit inside that flow. The status form only offers a pad while the ticket is still open; once it is resolved, the sign-off card owns the pad, so the page never shows two places to sign. And if a signature is offered alongside a status that does not finish the job, say waiting on the requester picked by mistake, the sign-off is refused with an error rather than quietly discarded. Better a loud message while the customer is still in front of the engineer than a mark thrown away because the wrong option was selected.
Recording a sign-off is part of resolving, so it needs the same permission as changing a ticket’s status. Viewing one back is part of reading the ticket. The web page and the mobile app go through one shared service, so the rule about when a sign-off can be taken is written once and cannot drift between the two.
Why a bad drawing is refused here and kept elsewhere
This is the part of the design that looks inconsistent until you see the reason, and it is the part most worth copying.
Elsewhere in AWRA, signatures are taken on stock transfers, count sessions, adjustments and asset movements. When the drawing on one of those cannot be stored, because the image is malformed or too large or the disk refused the write, the movement is still recorded and the operator is told plainly that the signature was lost and should be taken again. That is the right trade. A movement is a physical fact that happened whether or not the pad worked, and losing a stock transfer because a canvas misbehaved would be absurd. The window to sign those records stays open, so the mark can simply be retaken.
A ticket sign-off is the opposite case. The signature is the entire point of the request, and it is taken once. If the helpdesk kept the typed name and dropped the failed drawing, it would report success, lock the sign-off, and permanently shut out the drawing. The only way back would be reopening the ticket, which is a much heavier act than asking the customer to sign again right now. So when a drawing is offered and cannot be stored, the whole sign-off is refused, even if a name came with it, and the engineer is told to sign again or save the name on its own.
One rule, two outcomes
Keep and warn
Transfers, counts, adjustments, asset movements
- The record is a physical event that already happened.
- The signature window stays open after a failure.
- Refusing would lose the movement to save the mark.
Refuse loudly
The ticket sign-off
- The signature is the whole request.
- One mark locks the sign-off for good.
- Saving half of it would report success and close the door.
Both sides share the same capture code: it accepts only a PNG, sniffs the bytes rather than trusting the label, caps the size, and checks that the disk actually wrote the file. Only what happens after a failure differs.
The phantom signature
One failure mode is worth naming because it is easy to build by accident. If the code that stores the image does not check whether the write succeeded, the record ends up with a path to a file that does not exist: a named person apparently signed, the system hands out a link to their signature, and there is nothing behind it. The capture code checks the write and treats a failed one as a lost drawing, never as a stored one.
Reopening withdraws the agreement
A sign-off says the requester agreed the job was done. If the ticket goes back into the queue, that agreement has been withdrawn, and a “customer signed off” mark sitting on a live ticket is not stale evidence. It is wrong evidence. So the moment a finished ticket becomes active again, the name, the time and the drawing are cleared, and the stored image is deleted once the change is saved. The reopen itself stays on the record: the ticket counts how many times it has been reopened, and the internal thread note from the first sign-off is still there.
| What happens to a signed ticket | The sign-off | Why |
|---|---|---|
| Moved from Resolved to Closed | Kept | The job is still finished; closing it changes nothing the customer agreed to |
| Reopened to Open or In Progress | Cleared, image deleted | The agreement no longer describes the ticket |
| Cancelled after it was signed | Kept | Somebody did the work and somebody signed for it, which is what a reviewer asking about the cancellation wants to see |
| Cancelled, then picked back up | Cleared | It is live again, and this is the route by which a mark would otherwise survive onto a ticket being worked |
| Resolved again after a reopen | Can be signed afresh | The next resolution is signed for on its own terms |
This is also the answer to the customer who signed and then found the fault had come back. They do not need the signature changed. They need the ticket reopened, which clears the mark and lets the second visit be signed for separately. A signature that could be edited after the fact would be worth less to both sides.
Who can see it
The drawing is a personal mark, so it is served through the same guarded route as other stored files rather than from a public address. Agents who can view tickets in your organization see it on the ticket. A requester who raised the ticket through their own login sees it on their own ticket, read-only, under “Your sign-off”, on the web and in the app, and cannot reach anyone else’s. The file’s storage path never reaches a browser or the mobile app; the app receives a link it can only open with the right permission.
Showing it back to the requester matters more than it seems. The point of the sign-off is that the customer agreed. Letting them see what they put their name to, without being able to redo it, keeps the record honest in both directions.
What a sign-off does not prove
It is worth being clear about the limits of the evidence, because a signature invites people to read more into it than it holds.
- It proves agreement at a moment, not durability. The office manager agreed the reader worked at half past ten. That settles whether the engineer left a working door, which is the dispute in the opening story. It does not settle whether the reader will fail next month.
- It is only as good as the name. The pad is labelled for the requester, but on site the person signing may be a supervisor or a receptionist. Write down who actually signed, in full, and the record says exactly what it can support.
- It is not a satisfaction score. Resolving a ticket separately asks the requester for a rating, and they can revise that rating later. The sign-off is a different instrument: a statement that the work was done, taken once. Keep them apart, or one will be used to argue with the other.
- A signature collected under pressure is weak evidence. If engineers learn that a sign-off closes the conversation, some will ask for it before the test rather than after. The test comes first; the pad comes last.
A field practice that makes the sign-off worth having
- Test the fix with the customer watching, then hand them the device.
- Type their full name, not “site contact” or a first name.
- Resolve and sign in one action where possible, so the time on the sign-off is the time of the visit.
- If the customer will not sign, record that in the thread rather than resolving silently.
- If the fault returns, reopen the ticket; never resolve a second visit on top of the first sign-off.
The short version
On a desk ticket the requester is the check, because they will say if it is not fixed. On a field job they are only reachable while the engineer is still there, so AWRA takes their sign-off then: on a resolved or closed ticket only, once, with a printed name and the time doing the evidential work and a drawing as optional extra. A drawing that cannot be stored refuses the whole sign-off rather than being dropped, because one mark locks it for good. Reopening the ticket withdraws the agreement and deletes the image, so a signature never describes work that is being done again.
What AWRA OpsHub does today
- A requester sign-off on resolved and closed tickets, taken in the same action as resolving or afterwards from the ticket, on the web and in the mobile app through one shared rule.
- A printed name alone accepted as a complete sign-off, with the time recorded, and a hand-drawn signature stored alongside when one is taken.
- Signed once and locked, with no replace action for any role; the way back is reopening the ticket.
- A failed drawing refuses the whole sign-off instead of saving the name and reporting success, and an empty sign-off is refused too.
- Reopening clears the sign-off and deletes its image, while cancelling a signed ticket keeps it and the reopen count records what happened.
- An internal note in the ticket thread naming the signer, authored by the agent who collected it.
- Guarded access to the drawing: agents with ticket-viewing permission, and the requester on their own ticket only, read-only.
More we can add to your workspace
- A printed job sheet carrying the sign-off. The helpdesk renders no PDF today; a job sheet with the work notes, the signer’s name, the time and the drawing is a short build on the capture code, which already prepares signatures for printed documents elsewhere in the product.
- The collecting agent named on the sign-off card itself. Today that is the author of the internal thread note; putting it beside the signer’s name puts both halves of the handover in one place.
- A workspace setting that requires a printed name with every drawing, for organizations that want a drawn mark never to stand on its own.
- The sign-off shown on the emailed tracking page for requesters who raise tickets by email and have no login.
- Sign-off captured offline in the mobile app and sent when the signal returns, for basements, plant rooms and rural sites.
- A signer linked to a contact record, so a site supervisor who signs for many visits can be looked up as a person rather than as typed text.
Where we point you to a specialist
- We will not offer a way to edit or replace a sign-off on a finished ticket, for administrators included. A customer who disagrees with what they signed gets the ticket reopened, which keeps both the original agreement and its withdrawal on the record.
- We will not decide whether a signed sign-off amounts to acceptance under your service contract. That depends on the contract and the law that governs it, and it is a question for whoever reviews your service agreements.
The job sheet and the collecting agent on the card are the two that change most for a field team, and both sit on parts that already exist: the signature is already stored and guarded, and the agent is already recorded in the thread. The offline capture follows the pattern the mobile app already uses for its queued operations.
Anything above that you need, we can build for you
Everything listed above as something we can add describes what ships in the standard product today — it is a starting point, 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 whatever you just read about. One qualification so this is worth what it claims: a small number of things on this blog we deliberately leave to a specialist rather than build — 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. 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 additions, which are the ones readers ask for 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 needsFour questions for any helpdesk that claims field sign-off
Can a ticket be signed off before it is resolved?
What you will probably hear
The signature field is on the ticket form.
How to read it
Ask what the signature then says. A mark taken on an open ticket attests to nothing, and a system that allows it will collect signatures before the test.
What happens when the signature image fails to save?
What you will probably hear
It is very rare.
How to read it
Ask whether the agent is told. If the ticket saves and reports success without the mark, you will discover it during the dispute, which is the one moment you needed it.
Can a sign-off be replaced?
What you will probably hear
Yes, if the customer signs again.
How to read it
Then the record shows whichever version was taken last. Ask how you would tell that a first signature existed and was overwritten.
What happens to the sign-off when the ticket is reopened?
What you will probably hear
It stays as part of the history.
How to read it
Ask what the reopened ticket shows. A live ticket carrying a “customer signed off” mark is the evidence of the wrong visit.
See the AWRA helpdesk
Tickets, queues and service levels, with the requester’s sign-off on field work taken on the web or in the mobile app while the customer is still there.
Explore the helpdeskFrequently asked questions
When can a requester sign off a ticket?
Only once the ticket is resolved or closed. An open ticket has no finished job to sign for, and a cancelled ticket had no work done. The engineer can resolve and take the sign-off in one action, or open the resolved ticket afterwards and take it from the sign-off card.
Does the customer have to draw a signature?
No. A typed full name is accepted as a complete sign-off and the time is recorded with it. A hand-drawn signature can be added, and it is stored alongside the name, but the name and time are what identify who agreed and when.
What happens if the drawn signature cannot be saved?
The whole sign-off is refused with a message asking the person to sign again or save just the name. It is not saved half-way, because a sign-off is taken once and saving only the name would lock out the drawing for good.
Can a sign-off be changed after it is recorded?
No, by anyone. If the work turns out not to be finished, the ticket is reopened, which clears the sign-off and deletes the stored image. When it is resolved again, a new sign-off can be taken for that visit.
Does cancelling a signed ticket remove the sign-off?
No. Cancelling a ticket that was already signed off keeps the sign-off, because the work was done and signed for. If that cancelled ticket is later picked back up and worked again, the sign-off is cleared.
Can the requester see their own sign-off?
Yes, if they raised the ticket with their own login. They see the name, the time and the drawing on their ticket, on the web and in the mobile app, read-only. Agents with permission to view tickets see it on the ticket too.
