Internal Request Forms and Clear Staff Assignments
Build an internal request form, name one owner and a target date, then close each job with proof so work stops disappearing in team chats.
· Updated
At nine in the morning someone posts "can someone fix the chair in the meeting room?" in the office group chat. Two people read it, and each assumes the other will handle it. By late afternoon the requester asks again. The chair is still broken, and the manager has no idea whether the job ever made it into anyone's queue.
An internal request form turns messages like that into a record someone can act on. A form alone does not fix how work gets divided, though. Somebody still has to review the request, accept the assignment, and show the result before the record is closed.
You can start with one small flow: office facilities requests handled by the operations team. The same approach works for IT support or admin requests. Keep the flows separate when their access rules and checks differ; a payroll report has no business sitting in the same general queue as a chair repair.
Form fields people actually use
For example, a staff member submits a chair repair as request IR/2026/0042. They fill in the location, the problem, the date they need it fixed, and how the technician can reach them. The coordinator then assigns a technician and sets a target after looking at the problem.
| Field | Example entry | Filled in by |
|---|---|---|
| Request type | Facilities repair | Requester |
| Location | Jakarta office, 2nd floor meeting room | Requester |
| What is needed | Chair backrest is loose; chair has been set aside | Requester |
| Needed by | 5 November 2026, before 10:00 WIB | Requester |
| Impact if delayed | One chair unusable during meetings | Requester |
| Owner | Facilities technician A | Coordinator |
| Target date | 4 November 2026, 15:00 WIB | Coordinator and technician |
| Status | Scheduled | Coordinator |
| Closing evidence | Inspection note and requester confirmation | Technician and reviewer |
The "needed by" date is not a promise to finish. The requester states what they need, and the technician judges what is realistic. Keeping the two dates in separate fields makes the gap between expectations visible before the deadline slips.
The GOV.UK guide to structuring forms recommends knowing why you ask each question, what you will do with the answer, and which users need to provide it. Run that check on your own form. If every conversation happens through company accounts and nobody ever calls the phone number, stop making that field mandatory just because the old form had it.
Keep reviewing a request separate from doing it
A new record starts as Submitted. The coordinator checks whether the location and the need are clear enough to decide what to do. If they are not, the record goes back with a specific question, such as "which chair, and in which room?", instead of a bare status change to Incomplete.
Once the information is complete, the coordinator picks one owner. Others can help, but one person is responsible for keeping the record up to date. Assigning a job to "the operations team" with no name attached puts you right back where the group chat left you.
Use statuses that describe the state of the work: Submitted, Needs information, Scheduled, In progress, Waiting on someone else, and Done. Not every team needs all of them. Keep the ones that change what happens next, and skip the ones that only make the board more colorful.
Separate work requests from purchase requests as well. A technician can inspect the chair first, while buying a replacement may need its own decision. If the job creates a cost, link the record to your purchase approval flow rather than treating the assignment as permission to spend.
A work queue needs a reason for its priorities
The Urgent label is easy to pick when a requester wants fast service. Add questions about impact: what work has stopped, who is affected, and is there a workaround? The answers let the coordinator compare requests without favoring whoever sends the most messages.
In the chair example, the meeting room still works with one chair fewer. That is a different situation from a broken door lock that keeps people out of the office. Your team has to decide which conditions go straight to an emergency procedure; a regular request form is the wrong place to wait for someone to deal with a hazard.
When you hand out daily work, look at what each technician already holds. Four short jobs in buildings far apart can be harder to schedule than one long job in a single location. Record estimated duration or the need for a site visit when that detail actually helps with scheduling.
If a technician is on leave, the coordinator reassigns the work openly and notes why. Avoid quietly swapping the name. The replacement needs to know what was last done, what is blocking the job, and whom to contact, so they don't repeat the inspection from scratch.
A waiting status should name the next step
"Waiting on vendor" tells you nothing about whether the job is still moving. Record what you are waiting for, who follows up, and when it will be checked again. For IR/2026/0042, the note could say the technician is waiting for confirmation that replacement bolts are in stock and will check again on 4 November at 11:00 WIB.
The next check time is different from the target date. If the confirmation hasn't arrived, the technician updates the plan and tells the coordinator what it means for the schedule. Moving a deadline without a reason only takes the problem off today's overdue list.
Pick one place for the official record. Quick chats can still happen in the group, but decisions about schedules, reassignments, or inspection results go on the same request number. That number works like a parcel tracking number: everyone can point to the exact job without copying the whole conversation.
If you still run this in a spreadsheet, keep one row per request and a fixed request number. Before moving anything into a new tool, clean out duplicate copies of what is really the same request, or you will import the confusion along with the data.
Close on the result, not on a "done" message
The technician records what was done: backrest tightened, joints checked, chair returned to the meeting room. A reviewer then confirms the result matches the request. Photos help with some physical work, but don't require them when they would capture confidential documents or people who have nothing to do with the job.
Decide who is allowed to close a record. For simple work, the requester's confirmation may be enough. For work that needs a technical check, name someone with the right authority. If the result is not accepted, move the record back to In progress with the reason and the fix that is needed.
A common mistake is marking a job Done the moment the technician reports back, while the requester is still waiting for the repair to hold. Teams that hit this often add a Needs review status. Record the date the result was submitted and the date it was accepted separately if you need both when you look back at performance.
Review a handful of closed records in your team meeting. Look for requests that keep coming back, requests that arrived missing information, and jobs that were reopened. A count of completed tasks says nothing about the quality of the work or why the queue keeps growing.
Setting up the same flow in Sora
If assignments are getting hard to track, you can describe this flow to Sora: a list of requests with location, requester, technician, needed-by date, target date, status, and closing evidence. Sora's public pages describe settings for roles, branches, access to a person's own or assigned records, and reports built on fields such as status.
Review the proposed app before you apply changes. Test it with a staff account and a manager account, not just the owner account. Owners and admins have broad access, so what they see does not prove that staff restrictions work as intended. If requests contain sensitive data, also set up role-based access.
Sora offers public forms and status links, but anyone who has the link can open them. Calling a form "internal" in its name does not restrict who can reach it. Decide which fields are safe to share, and use the staff account flow when requests really must stay inside the team.
You can browse apps by business type to see how records are structured, then adjust the fields to match your team's work. Start today with one request type: take the five most recent work requests from your chat, turn them into five records, and make sure each one has a single owner and a next step before you add any new fields.