What an internal company portal is, why you need one and how to build it

An internal company portal is the one internal address employees open every day. Leave requests are submitted there, absences are visible there, announcements are published there, and that is where you find out who currently has which laptop.

A portal is not an accounting package or an ERP, and it does not try to replace one. Its job is to gather the processes that are specific to your company — the ones no ready-made product quite covers — in a single place, and to connect to the systems you already run.

This article answers three questions: what a portal is, why you would need one, and how it should be built.

1. A portal is an address, not a list of modules

Thinking of a portal as “a leave module plus an asset module plus an announcement module” is misleading. Modules are the outcome. The portal itself is your company’s internal way of working, gathered in one place.

The difference shows up in a concrete test. Where does an employee submit a leave request, where does their manager approve it, where does HR see it, and where does a colleague find out who is away that day? If all four answers are the same address, you have a portal. If there are four different answers, you are running four systems and four habits.

2. The need usually comes from one of three places

Scattered information. A system for leave, a spreadsheet for assigned equipment, a person to ask about meeting rooms, a chat group for announcements. Each looks small. The sum is the time spent looking for things.

Per-user licensing. Most off-the-shelf systems are billed per person. That ties your software costs to how many people you hire rather than to the work you do. As the company grows, the bill grows on its own, while you carry on doing exactly the same thing.

A product that does not fit. Ready-made systems are designed for an average company. If your approval chain has three steps and the product supports two, you either bend the process to fit the product or run it outside the system. Both choices have a price.

There is also a quieter threshold: the spreadsheet. Spreadsheets are genuinely good tools and they are enough for many processes. They stop being enough when three things happen — more than one person needs to edit the same file at the same time, someone needs to know who changed what, and the process grows an approval step.

3. Do not move everything into the portal

The most expensive way to build a portal is to rewrite what off-the-shelf systems already do well. This split works for most companies:

Keep it off the shelf	Move it into the portal
Accounting and bookkeeping	Leave requests and approval flows
Payroll and employment records	Assigned assets: phones, laptops, vehicles
E-invoicing	Meeting rooms and resource booking
Email, files, calendars (Microsoft 365, Google Workspace)	Announcements, news, internal communication
The ERP itself	Internal requests and fault tickets

What the right column has in common: every company does it differently, and your decisions set the rules. What the left column has in common: you do not set the rules, legislation does, and keeping up with changes is not your job.

4. The defining quality of a good portal is what it can connect to

A portal’s modules change over time. What does not change is the room to move that comes from owning the panel.

In an off-the-shelf product the question is always “does the vendor support this integration?” If the answer is no, there is nothing to do but add it to a wish list and wait. In your own panel the same question becomes “when shall we schedule this work?” That is not a technical detail; it is about who holds the decision.

In practice it looks like this. When someone books a meeting room, the room’s calendar can be read live from Microsoft 365, and the meeting created in the portal can be pushed to Teams. The same panel can show who reports to whom, along with phone numbers and email addresses. None of these is a large piece of work on its own; having them in one place is.

A good portal has these properties:

• Parts of it can be public. There is no reason to make people sign in to read the news, the announcements or this week’s lunch menu.
• Sign-in is a choice. It can be connected to Microsoft 365 accounts, or the portal can keep its own. This should be a decision, not a constraint.
• Permissions follow how the company works. It may make sense for everyone to see approved leave, while in the asset register each person sees only their own items, HR sees every record without being able to edit it, and IT can edit. Those calls belong to the company, not to a product.
• Access is logged. Who looked at what, and when, should be on record.
• Data sits on the company’s server. On an in-house server if there is one, otherwise on a server bought in the company’s name.

5. Where to start: a small core

Trying to finish a portal in one go is the slowest and most expensive route. A better one is to start with a small core that everyone opens every day.

A good core is usually this: users and permissions, news and announcements, special days such as birthdays, and the weekly lunch menu. With a tight scope that core is roughly ten hours of development, and it brings the whole company into the portal in the first week.

The main benefit is not technical. People cannot say precisely what they want from a system until they start using one. The requests that arrive after the core goes live are always sharper than the list produced in meetings held before anything was built.

When choosing the first real module, ask two questions: which process touches the most people, and which one wastes the most time in its current form? In most companies the answer is leave tracking.

6. Personal data: whose responsibility, and whose job?

A portal holds employee data, so the legal side needs to be understood correctly before deciding anything.

A company that processes its employees’ data for its own purposes is the data controller under GDPR and Turkish data protection law. That role cannot be handed over: not to the developer who builds the portal, and not to the company providing the server. Whoever builds and runs the software acts on the company’s instructions as a data processor, and that relationship has to be defined in the contract.

So there is no arrangement where outsourcing the work also outsources the responsibility. What can be done technically is clear, and a portal makes it easier:

1. Role-based permissions: who can see which data, and who can edit it.
2. Access logging: who looked at what, and when.
3. Data minimisation: not collecting data you have no use for.
4. A hosting decision: knowing which server, in which country, holds the data.
5. Retention: deciding up front when old records get deleted.

In an off-the-shelf system most of these five are limited to whatever you are offered. In your own panel you make the call.

7. A real example: a packaging manufacturer with more than 300 employees

KRCPACK used a separate system for leave tracking and had nothing at all for meeting rooms. Their leave system had no calendar, so there was no single view of who was off and when. The quotes they received for a broader internal panel came with a per-user annual licence.

We built the portal from scratch, around the way they actually work. Today it runs manager-approved leave tracking, HR and vehicle asset assignments, news and announcements, the weekly lunch menu, birthday and anniversary greetings, meeting-room management, IT ticketing and reporting. Meeting-room calendars are read live from Microsoft 365.

The outcome fits in two sentences. The company now has a single panel it can grow as it likes, with no per-user licence. The portal has been in use since June 2026 and is still growing; today the whole monthly hour package goes into it, because using it keeps producing new requests.

That last sentence is not a shortcoming. It is the expected behaviour: companies change, and portals have to change with them.

8. How to do the maths

Whether to build a portal or buy a system does not reduce to one sentence, but the arithmetic is simple.

On one side write: number of users × annual per-user licence × number of systems you use, totalled over three years. On the other side put the portal’s setup hours, its monthly development hours and the server cost.

When comparing the two, remember this: the first figure grows as your headcount grows, even if you do nothing at all. The second does not; it only rises when you ask for new work.

The decision is not only about money, though. An off-the-shelf system is the right answer when the process is bound by legislation, works the same way in every company, and you have no particular way of doing it. A custom panel pays off where the way you work is specific to you, where the ready-made product is either missing something or full of things you do not need, and where the process will keep changing.

Three questions are worth answering before any conversation about a portal: is this process specific to your company, what makes your bill grow, and whose server will the data sit on?

Arriving with those answers makes the first call much shorter. You can read what I do on the internal portals and back-office systems service page, see the details of the working model in how I work, or simply request a free introductory call.