A request that arrives by email is easy to send and surprisingly expensive to manage. Someone has to read it, work out what is needed, chase missing details, decide who owns it and update the requester later. Multiply that by quotes, maintenance jobs, onboarding tasks, purchase requests or customer changes, and the inbox becomes an unplanned workflow system.

Knowing how to build request portals is not mainly about putting a form on a website. It is about creating a controlled front door for recurring work, so the right information reaches the right person and nobody has to reconstruct the request from a chain of emails.

Start with the request, not the portal

The common mistake is to begin with screens, fields and logins. Start instead with one real request from the last week. Follow it from the moment it was raised through to completion. Ask who submitted it, what information was missing, who handled it, what decisions were made and where the final record now lives.

This usually exposes the real problem. A maintenance team may think it needs a job request portal, but the underlying issue could be unclear asset details and no way to assess urgency. A sales office may ask for a customer amendment form, when the harder issue is that changes are copied between a CRM, accounts package and spreadsheet by hand.

A portal should standardise a process that is already understood, while improving the parts that cause delay or errors. If the process itself is uncertain, agree the operating rules before writing software. Otherwise, the portal simply makes a confused process look more official.

Decide what success looks like

Request portals work best when they solve a specific operational problem. A good first version might reduce incomplete requests, cut status-chasing calls or make it clear who is responsible for the next action. These are practical measures that people can recognise.

Avoid setting a vague goal such as “digitise requests”. Define the change in plain terms. For example: every new supplier request must include company details, required documents and a commercial owner; requests must be approved before accounts creates a record; the requester can see whether it is awaiting approval, in progress or complete.

That definition helps prevent scope from expanding into a full replacement for every system in the business. A request portal does not need to do everything. It needs to do the intake, routing and visibility job properly, then pass information to other systems where appropriate.

How to build request portals around real users

A portal may serve employees, customers, suppliers or a mixture of all three. Each group needs a different level of guidance and access. Internal staff might understand internal terminology and need to make frequent, detailed requests. Customers should see only what they need to provide and the progress that is relevant to them.

Keep the first screen focused. The user should be able to answer three questions quickly: what can I request, what information will I need, and what happens after I submit it? If those answers are unclear, people will return to email or start submitting poor-quality requests.

For each request type, map the minimum information needed to make a useful first decision. This is not necessarily every detail needed to finish the work. Asking for too much upfront discourages use and produces guesswork. A repair request, for example, may need a site, asset, fault description, contact and photographs at submission. The engineer can gather technical detail later.

Conditional questions are often more useful than a large form. If a requester selects “new starter”, show start date, manager, equipment and access needs. If they select “leaver”, show final working day and handover requirements. The form stays short while the team receives the information it actually needs.

Design the workflow before the screens

Behind every useful request portal is a clear workflow. At a minimum, decide what happens after submission, who owns the request at each stage, what can send it back, and what counts as complete.

Status labels need to mean something. “Open” and “closed” are rarely enough. A small set of plain-language statuses is usually better: submitted, awaiting information, awaiting approval, assigned, in progress and completed. Do not create a status for every internal nuance unless users genuinely need to act on it.

You should also decide which actions need approval. Approval is useful where a request creates cost, risk or a permanent change, such as buying equipment, granting system access or altering customer records. It is less useful when it becomes a default obstacle. Requiring a manager to approve routine requests can create a queue with no real control benefit.

Set ownership explicitly. A shared team inbox has no natural owner; a portal request should. It may be assigned to a named person, a team queue or a role, but someone needs to be accountable for moving it on. Automatic routing can use request type, site, department, customer, value or urgency, provided the rules remain understandable.

Connect the systems that already matter

A portal becomes more valuable when it removes duplicate entry. That does not mean every system must be integrated from day one. Start with the points where rekeying creates mistakes or wastes significant time.

For instance, an approved customer change might update a CRM, create a task for accounts and retain the approval record against the request. A new job request could pull known customer and site details into the form, then create a job in the operations system once triaged.

There is a trade-off. Integrations add value, but they also add dependencies and need proper testing when a third-party system changes. For a low-volume process, a structured export or a controlled hand-off may be the sensible first step. For a high-volume process with repeated data entry, direct integration is usually worth the effort.

Think carefully about the source of truth. If customer details are owned by the CRM, the portal should display or request changes to that data rather than becoming a second customer database. Clear ownership prevents conflicting records and the familiar question of which spreadsheet is correct.

Build for exceptions, not just the happy path

Most processes work neatly until an incomplete request, a duplicate submission, an urgent issue or a missing approver appears. These are not edge cases in a growing business. They are normal working conditions.

Make room for a handler to request more information, reassign work, merge duplicates and record why something was rejected. Let requesters add a comment or attachment after submission if it helps resolve the work without starting again. Keep an activity history so staff can see what happened, when and by whom.

Permissions deserve the same practical approach. A requester should see their own requests. Managers may see their team’s requests. Operational staff need the records they handle, while sensitive information such as HR matters, pricing or security access should be limited to the appropriate people. The right model depends on the process, but access rules should be agreed early rather than bolted on later.

Keep the first release small enough to improve

A useful portal is rarely perfect at launch. The sensible approach is to release one high-value request type, use it with a real group of people and adjust it based on evidence. Watch where users abandon forms, which fields are regularly corrected and which requests still arrive by email.

Before launch, test these practical situations:

• A requester submits complete and incomplete information.
• A request needs approval, more detail or reassignment.
• A handler is absent and work needs to move to someone else.
• A user can see the correct status without contacting the team.
• The process leaves a usable record for reporting and audit.

Measure the results after a few weeks. Look at request volumes, turnaround time, incomplete submissions, requests received outside the portal and the time spent on status updates. Numbers matter, but so do comments from the people doing the work. If a team keeps a side spreadsheet, find out why. It may reveal a genuine need the first release did not cover.

Choose a delivery approach that fits the business

Some request processes can be handled well with existing software and configuration. Others need a bespoke portal because the workflow crosses several systems, has unusual rules or must reflect how the business actually operates. There is no prize for custom development where a standard tool genuinely fits, and there is little value in forcing an important process into a tool that creates workarounds.

The key is to assess the process, data, integrations and likely future changes together. Businesses often benefit from working with someone who can map the operation and build the solution, rather than passing requirements between a consultant, project manager and developer. It keeps decisions close to the people who understand both the commercial need and the technical consequences.

A request portal earns its place when it makes work easier to start, easier to manage and easier to account for. Begin with the request that causes the most avoidable chasing. Fix that one properly, and the next improvement becomes much clearer.