How To Write Requirements For A Custom Operations Portal

Most process pain has nothing to do with effort. Smart people work hard around a system that was never designed to carry the work, and everyone mistakes the symptom for the cause.

Let us talk about how to write requirements for a custom operations portal, and the part that actually hurts: role confusion where everyone sees everything and no one owns anything. The point here is not to add tooling. It is to find the one place the portal quietly depends on a person and decide whether that is safe.

01Where the time really goes

The failure mode is almost always the same. Each tool around the portal is fine on its own, and the work still stalls in the space between them, because no one formally owns the moment a record moves from one system to the next.

When the portal is working, four things are usually true:

1. A new hire can find what is stuck without asking anyone
2. A quiet week does not mean the backlog is silently piling up
3. Work moves on its own instead of waiting for a nudge
4. Ownership is obvious for every handoff

02A real operator scene

A partner portal launches with one view for everyone. Within a month, people ask for the parts that matter to their role and ignore the rest. The layout was faithful to the old file and blind to who actually needs to decide what.

Notice that nobody in that story is doing anything wrong. The portal was never designed to carry the work end to end, which is exactly where HATT starts: find the worst handoff, give it an owner, and build the narrow system that holds it. More on that here: ai automation without hype where it actually helps business workflows.

03How to diagnose it

Run the process through these before you spend anything:

1. Would the old spreadsheet quietly come back if you watched for a month
2. Who owns each status change, and is that ownership visible
3. Does each role see what they need to decide, or does everyone see everything
4. Does the portal capture the exceptions the old sheet handled by hand
5. Can someone still answer a client only by taking a screenshot

If the answers are fuzzy, map the portal before spending on anything new.

04Where to start if you do build

Do not try to boil the portal down to one perfect build. Find the step that hurts most when it slips, own that, and let the rest wait until it has earned its own version.

A sensible shortlist for a first version:

• The one status question a client asks that today needs a screenshot
• A role-aware view so each person sees only what they must decide
• The status change nobody currently owns in a visible way
• The exceptions the old sheet absorbed that the shiny portal quietly dropped

The downside of building too early is real, and so is the risk of buying too long. For the portal the boundary is the exception: when the rare case keeps landing on one person and it hurts when they are out, that is the signal a workaround has quietly become a liability.

05FAQ

Should a portal mirror our spreadsheet?

It should mirror the decisions, not the columns. Model who owns each step, what can get stuck, and which exception needs a person, and the portal earns its place instead of becoming a prettier sheet.

Why do internal portals get abandoned?

Because they copy the layout of the old file instead of the workflow underneath it. If the portal cannot handle the exceptions the sheet used to absorb, people drift back to the sheet and run both. See also when a spreadsheet should become a database backed workflow.

06If you take one thing from this

If the portal still needs a scramble before every review, the system is not carrying the work. Treat that as a product problem for your operations, not a discipline problem for your team.

If you want a second set of eyes on where the portal actually breaks, HATT maps the workflow first and scopes a first version that removes the worst step. You can book a scoping call to talk it through.