Corporate portals and internal systems
Corporate portal and internal systems development for employees: records, requests, approvals, reference data and reporting. We build around your process and connect it to what is already in place.
An internal system differs from a client-facing service in that there is no walking away from it. A client who finds it inconvenient simply closes the tab. An employee opens this system every day and spends eight hours in it. So an extra click here is multiplied by the number of people and the number of working days and turns into very specific money.
The main risk follows from that. A system that adds work for a person will be worked around by that person: they will start their own spreadsheet, settle it in a messenger, enter the data at the end of the month backdated. Formally the system exists, in practice the data in it is unreliable, and part of it exists only in one employee head.
The business learns the true price of this at the moment a key employee leaves. The data has to be extracted from the person themselves, from their files and their chats, and if they left for a competitor the damage is several times greater than the investment in a proper system would have been. Sooner or later every owner comes to think about this, and sooner is better.
So we design from the person who enters the data, and at the same time from how critical that data is: what happens if it is lost, what happens if it leaks. The same thing determines what the person reading the reports later sees. All of it is worked out at the design stage, and not always in money, though the loss at the end always turns out to be monetary.
The second point is the zoo. A company usually already has an accounting system, bookkeeping, mail, a messenger, and sometimes several systems doing the same thing. An internal system is rarely the first one, more often it becomes the connective tissue: it collects data from what exists and hands it back. So we start with a review of what already works and reuse everything we can.
The third point is access. Inside a company data is divided between departments and levels, and that division is not a formality: salaries, contracts, personal data, commercial terms. Roles, permissions and an audit log are designed from the start rather than added after the first unpleasant incident.
A system like this is built as server software with a backend, a frontend and infrastructure inside one team. Alongside it usually run business process automation, bots for routine operations, language models and analytics. If the system is for clients rather than employees, see online services. If something already runs and it is unclear what to do with it, start with an audit or IT consulting.
What the service covers
Any combination of the items below can be taken on its own.
A single point of entry for employees: tasks, documents, reference data, news, contacts, requests to departments.
Clients, contracts, assets, equipment, stock, staff. Data is entered once and lives in one place rather than in six spreadsheets and somebody memory.
Intake of tickets from mail, messengers and a form, queues, deadlines, owners, correspondence history and a workload report.
Who sees what, who changes what, who deleted what and when. Boundaries by department, level and object.
Accounting and bookkeeping systems, mail, messengers, telephony, hardware. We work even where there is no documentation.
We go through what has accumulated, clean it, migrate it and run in parallel so that people are not left without data during the move.
How we work
What is already in place, who uses what, where data is duplicated, where it is lost and where it exists only with one person. We talk to those who work inside this every day.
What we build, what we integrate, what we leave as it is. Roles, permissions and the criticality of the data are described here too. An estimate by stage.
Two-week iterations. The first module we build is the one that removes the most visible pain.
Cleaning, migration, running in parallel with the old solution, help with training the staff.
Refinements based on feedback, new modules, updates and on-call duty.
Stack and tools
Cases for this service
Frequently asked questions
If your processes are standard ones, a ready product is cheaper, and we will say so. Building your own is justified when the ready product fits only halfway, when licences are counted in hundreds and thousands of workplaces, or when the process itself is your advantage.
With a review and one module. We do not switch the spreadsheets off straight away: the system runs in parallel until the data in it is fuller and more convenient than in the files.
Yes, that is an ordinary part of the work. If a system has no documentation, we work out the protocol ourselves.
That is the main risk of a rollout, and it is removed at the design stage. We talk to the people who will be entering the data and make sure the system saves them time.
That is exactly why the data and the processes should live in a system rather than in personal files and chats. Then a person leaving stays a staffing question instead of turning into a loss of information.
Everything is set by the contract, and we put it in writing at the specification stage, before the work starts. During the project the team works either on our infrastructure or on yours: the choice depends on the complexity of the project and on whether you already have infrastructure in place. Every approved stage is transferred to your servers and your repository, so the work accumulates on your side rather than ours. Once the project is closed, all code, materials and documentation are handed over to you together with the rights to them.
Yes, under a separate agreement: refinements, new modules, updates and on-call duty.
Related services
Shall we discuss your task?
Tell us what needs to be done and we will come back with an estimate, the team composition and a plan for the first two weeks.