A second click needs a rule
Define what counts as a repeated request, what signals new intent and who checks an uncertain result. A filled rule note for an imagined repair process.
What should happen when the first submission has no clear result?
Imagine someone requests a repair for an office printer. They complete a form and press Submit. The page gives no clear answer, so they press it again. Later, a coordinator finds two similar requests.
The coordinator needs to know whether those entries represent two attempts to finish one action or two pieces of work the person wants.
For a team leader, the first job is to agree that meaning and what should happen when the answer is uncertain.
Decide what counts as the same action
In this example, trying again to finish the original submission would count as a repeat. A request for a different printer concerns separate work, even if the description is identical.
An amendment needs a rule too. If the person adds a different contact number after submitting, should that update the existing request or start another one?
We would treat matching names or descriptions as clues, then check whether they refer to the same intended request. The team needs to agree what information connects an attempt to an existing request and what happens when that connection cannot be established.
For this example, we would propose keeping repeat attempts associated with the original request wherever its identity can be confirmed. A deliberate request for another repair would start separate work. An unclear match would need review.
Make the message match what is known
The feedback needs to distinguish a confirmed receipt from an uncertain outcome. A proposed message such as “Request received” belongs after the system can confirm that the request exists.
For this example, receipt would confirm that the request exists, without implying that anyone has accepted the repair.
If receipt cannot be confirmed, the message should say that and explain the agreed next step. It should only promise a staff check if the workflow actually gives someone that responsibility.
The wording depends on the information the system can provide.
Give uncertainty an owner
In the imagined repair team, a coordinator could own unresolved submissions. Their first step would be to inspect the request record and any available submission history.
If the original request is confirmed, the coordinator can use that record to explain its status. If two records refer to one intended repair, the team needs an agreed way to retain one working request while recording how the second was resolved.
If the evidence remains unclear, the coordinator may need to ask the requester what they intended. The note should identify who makes that decision and who covers the task when the coordinator is unavailable.
A repeat action rule note
For this imagined project, a starting note could read:
The action: Submit one equipment repair request.
A repeat: Another attempt to finish that same request. Associate it with the original where the relationship can be confirmed.
New intent: A deliberate request for another repair creates separate work. Changed details need an agreed amendment route.
Known result: Show receipt only when a request record is confirmed. Keep receipt distinct from acceptance of the repair.
Unknown result: Explain that receipt is unconfirmed. The coordinator checks the available records before deciding whether to use an existing request, clarify the intention or arrange a new submission.
Owner: The coordinator, with a named cover person.
Open questions: How can attempts be linked? Which information reaches the coordinator? How are amendments handled? What record remains when two entries concern one repair?
This note is a proposed operating rule. The form, records and connected systems would still need to be checked against it.
Write a repeat action rule note for one request in your business, including what counts as new intent and who resolves an unknown result.
Prepared for WGMI with AI assistance.