A new system built around your process, connecting the systems already in use, or modernising a core that no longer keeps up, with maintenance after implementation.
See the serviceOperational portals
A place where a customer, partner or employee submits an application, order or ticket on their own and checks its status, while the service team sees every case in one view.
Scope
What clients come to us with
A customer calls to ask what is happening with their case
A customer sent an application or an order by e-mail and does not know what is happening with it. They call, an employee looks for the case in the mailbox and in the system, then calls back. One case triggers several conversations, none of which moves it forward.
Partners and agents submit orders in spreadsheets
A network of agents, partners or subcontractors sends orders in spreadsheets and messages, each in its own layout. An employee retypes them into the system and sends back confirmations. A data error only shows up at fulfilment, and the partner cannot see the state of its orders or settlements.
Employee requests circulate between mailboxes
A request for leave, equipment, system access or a legal opinion goes by e-mail to HR, IT or legal. Nobody sees how many requests are waiting, and on whom. When someone from the department leaves, the request history disappears with their mailbox.
Scope
What we do
An operational portal is a website with a login through which a customer, partner, agent or employee submits a case and follows it to the end. A case is an application, an order, a ticket or a request for a document. The portal sits on top of the systems the company already has: it reads customer data from the CRM, the sales system, and order status from the ERP, the billing and warehouse system. It saves a submitted case where the service team handles it anyway, so no second customer database grows up next to the current one.
Accounts and permissions: who can log in and what they see; customers their own cases, agents their customers' cases, the service team all of them. Case forms: fields checked as they are filled in, so that an application without an attachment or with a wrong number does not reach the company. Status and history: every step recorded with a date and a person, visible to both sides, with an e-mail or text message notification when it changes. Documents: invoices, contracts and confirmations generated from data in the company's systems, ready to download without asking an employee.
On the company's side there is a service team panel: a list of cases, who is waiting, on whom and since when, assignment to people and replies in one place. The team can open a case on behalf of a customer who phoned, so that phone and portal end up in the same register. Every login, case submission, status change and document download goes into the event log, a record of who did what and when, needed for complaints and audits.
If the company's systems do not yet exchange data with each other, connecting them is a separate scope. If no system stands behind a case, a custom system comes first, also as a separate scope. Personal data passes through the portal, so before the build we establish what data it stores, where that data sits and who has access to it.
Scope
What you get
- A case map: what customers, partners and employees handle by phone and e-mail, who handles each case in the company and in which system it ends.
- A portal design: screens, roles and permissions, the workflow of each case and the wording of notifications, for approval before the build.
- A portal in the cloud in the European Union or on your servers, with accounts, forms, status, history and documents, that also works on a phone.
- A service team panel with the case list, assignment, replies and event log.
- An administrator's guide for the person on your side who manages accounts: how to add a case type, grant permissions and read the log.
Scope
How the work runs
- We list the cases. We talk to the service team and look at where each case ends in the systems. Outcome: a case map and the order in which cases move to the portal, starting with those that take up the team's time most often.
- We design the portal. We set the roles, the workflow of each case, the notifications and the way data is read from the company's systems. Outcome: a design of screens and workflows checked with the people who will use it.
- We launch case by case. We open the first case type to a selected group of customers or partners, or to one department, collect comments and add the next ones. Outcome: cases handled in the portal, with phone and e-mail kept for those not yet in it.
- We hand over the portal. We train the service team and the administrator and hand over the documentation. Outcome: the portal run by your team; maintenance and development after launch is a separate scope.
Scope
Team experience
Members of the team launched an online sales channel for travel insurance policies for a client in the insurance sector, on a global scale. For a client in manufacturing and trade the team built an intranet, an internal website for employees, together with a company knowledge management system. For a public-sector client in Poland, members of the team customised JIRA, a system for receiving and managing tickets, and automated HR, IT and legal processes.
Scope
Questions the board should ask the portal contractor
- What does a customer see when their case is waiting for a decision: the stage, the person, the date of the last change?
- Where does the portal get customer and order data: from our systems or from its own copy, and what happens when they differ?
- Who removes permissions when a partner's employee leaves, and how long does it take?
- How long does the portal keep applicants' personal data, and who on our side can delete it?
- How is a new case type added: through settings available to our administrator, or by commissioning the contractor?
- What will the event log show when a customer says they submitted an application and the company cannot see it?
Which cases go into the first version of the portal and which systems it has to connect to is established by the process analysis, and that is where we start.
Parent service
Systems and integrations
Book a meeting
Book a conversation about the problem
You describe the process or system that no longer keeps up and what has to change. The conversation costs nothing.
Phone: +48 455 406 404
Custom systems
A system built around your process where a ready-made product would force a change in how you work, with code and documentation that belong to your company.
See the scopeConnecting systems into one whole
One place through which the ERP, CRM, industry system and spreadsheets exchange data on their own, with a description of each exchange and a view of whether it works.
See the scopeModernising systems already in use
Your system rebuilt one part at a time without stopping work: knowledge of it recorded in tests, components on supported versions and code that can be changed.
See the scopeMaintenance and development
Your system after launch in the care of the team that built it: fixes, changes driven by the process and regulations, component updates and monitoring, in an order you set with us.
See the scopeHow we start
A conversation about the problem
You describe the process or system that no longer keeps up and what has to change. The conversation costs nothing.
Analysis under an NDA
We examine the process and the systems and hand over a recommendation with a scope of work. You know the scope, deadline and price of the analysis before it starts.
Offer
You receive the scope, team, schedule and price of the implementation. You decide whether we go ahead.
The cost of the analysis is credited towards the implementation if you order it.
Phone: +48 455 406 404 E-mail: contact@aliaxit.com





