Troubleshooting: establish what the client observed
Ask whether the client saw a confirmation, a request identifier or only a loading screen. Keep the approximate time and intended service. These observations help distinguish a visibility issue from an uncertain submission. Do not call the request lost simply because it is absent from one board view. A filter, status or organization context may hide a record that was successfully created and is waiting for attention.
Check the narrowest relevant views
Review the intended client’s service, the request list and applicable status filters using authorized access. ManyRequests documents several ways to filter and manage requests. A queued item can appear differently from active work, especially when service limits apply. Look for the original brief or identifier rather than creating a new record with similar text. Keep unrelated clients’ information out of screenshots or messages used to resolve the issue.
Treat an uncertain outcome honestly
If no record can be established, distinguish “not found in the checked views” from “definitely never submitted.” Network interruption can leave the user uncertain about what the server accepted. Record the checks already made and seek a supported way to confirm the result before retrying a consequential action. Do not promise that a resubmission cannot create duplicates merely because the original screen appeared to fail or remained loading.
Restore one coherent work trail
When the original request is found, continue there and explain where it appears. If a duplicate already exists, identify both records before deciding which supported correction is appropriate. Preserve useful comments and attachments; do not discard a record solely because it is inconvenient. Review whether clearer intake confirmation or onboarding instructions would prevent the same confusion next time. The improvement should reduce client effort without concealing uncertainty or overwriting history.
Sources used for this page
These records support the facts and comparisons above. Merchant-controlled records are labelled so you can separate product claims from independent evidence.
- ManyRequests managing requests and exporting data — Merchant documentation · help.manyrequests.com · Merchant-controlled · checked 2026-09-19
- ManyRequests client experience — Merchant documentation · help.manyrequests.com · Merchant-controlled · checked 2026-09-19
- ManyRequests active and monthly request limits — Merchant documentation · help.manyrequests.com · Merchant-controlled · checked 2026-09-19