Operations · Custom Build
Internal request portal for IT and operations
IT and ops requests left Slack DMs and got a submit-route-status flow the team can actually track.
Example build — representative of the kind of engagement we take on, not a named client project.
Visual coming soon
Screenshot of the request queue — type, owner, status — plus the submit form.
The problem
Requests lived in DMs, so nobody had a queue and nobody knew if they’d been seen.
Laptops, access, vendor questions, and facilities issues arrived as Slack pings in different channels.
The build
Pick a type, submit, get a ticket the requester can see.
Routing sends it to the right owner. Status is visible without a follow-up ping, and the portal replaces the DM as the record.
The result
“Did anyone see my message?” stopped being the intake process.
Ops has a queue. Requesters can see where a ticket stands without chasing anyone.
Who it's for
For an ops lead whose queue is a Slack DM.
IT and operations teams at small companies. Laptops, access, vendor questions, and facilities issues arrive as pings in different channels. Nobody has a queue, and the requester cannot tell whether the message was seen.
What it replaces
- Slack DMs for laptops and account access
- Vendor and facilities questions scattered across channels
- A queue that exists only in someone’s memory
- Follow-up pings that really mean “did anyone see this?”
How it works
1. Pick a type and submit
Laptops, access, vendors, and facilities each have a path. The request starts as a form, not a direct message.
2. Routing picks the owner
The ticket goes to the person who handles that type, so intake is not “whoever happened to see the channel.”
3. The requester can see status
The ticket is the record. Checking where it stands does not require a follow-up ping.
4. Ops has a queue
The portal replaces the DM as the place a request lives. Seen, owned, and done are visible.
Stack
- TypeScript/Node.js
- Postgres
- Next.js
Questions teams ask
Is this a live help desk installed for a client?
This is an example build. It shows an internal request portal of the kind we scope for operations and IT teams. It is not a named client project.
What belongs in an internal request portal?
The requests that currently arrive as Slack pings: laptops, access, vendor questions, and facilities issues. Each one gets a type, an owner, and a status.
How is an internal request portal different from Slack?
Slack is still where the team talks. The portal is the record: submit, route, and a status the requester can see without asking if anyone saw the message.