An internal request portal for operations and admin requests

Direct answer

An internal request portal is a web application where staff submit operations and admin requests (access, purchases, equipment, changes, facilities, data corrections) through structured forms. Each request gets an owner, a status and a history, so nobody has to ask in chat whether something was seen. LATYNEX designs and builds these as custom internal web applications, delivered directly and remotely, in English.

The value is not the form. It is that every request has exactly one record, one accountable owner at any moment, and a visible age. This page covers how to design that; it is narrower than a general internal business tool and different from an approval workflow, which handles the decision step rather than the intake and tracking around it.

Start with request types, not screens

List the requests your team actually handles today by scanning the last month of inboxes and chat channels. Group them into types that share a handler and a process. Most operations teams end up with a handful of real types and a long tail of oddities.

• Recurring and predictable: give each its own form and route
• Rare and irregular: route to a general type with a free-text form and a triage owner, and promote it to its own type only when it repeats
• Requests that are really approvals: keep them here for intake, and hand the decision to a dedicated approval flow
• Requests that belong in another system already (a support desk, an HR tool): do not duplicate them; link to that system

Forms and the data they must collect

Most delays come from a request that arrives incomplete and needs three replies to become actionable. Decide the minimum data per type and make the form refuse to submit without it. Work backwards from the person doing the task: what would they otherwise have to ask?

• Who is asking and on whose behalf (requester and beneficiary are often different)
• What exactly is needed, chosen from options where possible instead of free text
• By when, and why that date, so urgency is a stated fact rather than a tone
• Attachments only where they are truly needed
• Conditional fields that appear by request type, so simple requests stay short

Routing and owners

Routing is the rule that turns a submission into someone's task. Keep it boring and explicit: request type plus a few attributes (team, location, category) maps to an owner or a shared queue. Every request must have a named owner within one working step of submission; unowned work is where requests die.

Plan for absence and reassignment from the start. A queue with a triage person, a backup owner per type and a manual reassign action costs little to build and prevents the most common failure, which is a request stuck with someone on leave.

Status and SLA visibility

Requesters stop chasing when they can see where their request is. A small set of statuses works better than a detailed one: submitted, in progress, waiting on requester, waiting on a third party, done, declined. Each change is timestamped and attributed.

If your team commits to response or completion targets, store the target per request type as a business rule you define, and show how long each open request has been in its current status. The portal should show the age; the target itself is your operating decision, not something we supply. Requests waiting on the requester should pause visibly so the owner is not blamed for silence they cannot fix. For a view of stuck work across many stages, see an operations bottleneck dashboard.

Roles and what each can see

Decide roles before building. A typical set is requester (sees only their own requests), handler (sees and updates requests routed to them), team lead (sees the whole queue and can reassign) and administrator (manages request types, forms and users). Sensitive request types, such as those touching personal or financial data, may need narrower visibility than the rest.

Access is granted per person inside the application. We do not promise integration with a specific directory or single sign-on provider as a default; if you need one, it is scoped as a separate item after checking what your identity system supports. The design principles are in roles and permissions for web applications.

Reporting from the same record

Because every request is a structured record, reporting becomes a by-product rather than a monthly chore. Useful questions include which request types repeat most, where requests wait longest, which are returned for missing information and who is overloaded. The answers drive real changes: repeated types deserve automation, frequent missing information means a form needs fixing, and chronic waiting points to a staffing or handoff problem.

What to keep out

A portal fails when it tries to absorb everything. Keep these out of the first version.

• Customer-facing support tickets, which have different needs and belong in a support tool or a [client portal](/client-portal-development/)
• Complex multi-stage approvals with conditional thresholds, until intake and tracking are working
• Project management, task boards and time tracking
• Deep integrations with every system in the company; start with the one that removes the most re-keying, scoped per project where an API exists
• Request types nobody has handled more than once

A sensible way to start

Pick the two or three request types that cause the most chasing, build those with their forms, routing and statuses, and run them with one team for a few weeks. Add types only when the first ones behave. If you are unsure whether a portal, low-code tool or spreadsheet is the right shape, read low-code vs custom internal tools or run the automation opportunity finder to see which repeated tasks are worth systemising first. When you are ready to scope it, the parent page is internal business tools.