How to choose an employee portal: a 25-question RFP checklist

You have watched demos from three vendors. All three look good on screen, all three say “we can do everything”, and a week later you have nothing you can compare. Choosing a portal is less about liking a piece of software than about measuring whether it fits the way your company works, and you cannot measure that with screenshots. The answer is a simplified version of the method known in corporate purchasing as an RFP: ask everyone the same questions in writing and put the answers side by side. That way the decision rests on commitments in writing, not on the impression left by a demo.

An RFP (request for proposal) is a written request in which an organisation sets out its needs and questions about the solution it wants to buy and asks vendors for proposals on the same basis. For choosing an employee portal, this means a needs summary of a few pages and a list of questions.

What is an RFP and how does the RFP process work?

In large corporate purchases an RFP is often a document dozens of pages long. For choosing an internal portal, a much lighter version is enough. The process usually runs in this order:

1. Write down the need. Which processes are scattered, who will use the portal, from which devices? Keep it to one page; there is an example below.
2. Keep the vendor list short. Choose only as many vendors as you can work with in depth.
3. Send everyone the same list of questions. Do not adapt the questions to one vendor; comparison is only possible with the same questions.
4. Ask for written answers and leave the demo for later. There is no need to watch a demo from a vendor whose written answers you found inadequate.
5. Score the answers with weights. Give higher weight to the areas that are critical for you.
6. Start small. Try the winning solution in one or two processes, not across the whole company at once.

Sample needs summary: Leave, asset assignment and visitor records are scattered across e-mails and spreadsheets. Some employees work in the field and do not use corporate e-mail. Our goal is to move these three processes into recorded workflows, manage permissions by role and let employees use the system from their phone without installing an app. The proposal must state clearly where the data will be kept and how it will work with existing systems.

Choosing an intranet works the same way. First clarify what the decision is about: are you looking for an internal site that only shares announcements and documents, or a portal where work such as leave, asset assignment and requests is handled? The answer determines which of the questions below you will give more weight to.

25 questions for your RFP

There are five questions in each of five areas; the numbering restarts in each area and adds up to 25. You can send the questions to vendors as they are. Do not settle for a “yes” or “no”; for each question, ask for the answer to “how?” as well. For example, if a vendor answers “yes” to “can it be used on mobile?”, expect them to show how an employee opens a leave request on the phone from start to finish.

A. Hosting and data

1. Where does the system run: on our server, in the vendor’s cloud or on a third-party service?
2. Who manages our data and where is it located? Who is responsible for backups?
3. What are the technical requirements? Do they fit our existing infrastructure and our IT team’s practices?
4. In what format do we get our data back when the contract ends?
5. What protection measures are there for sensitive fields such as national ID numbers and IBANs?

B. Roles and permissions

1. Can menu and data access be defined separately by role, department and user?
2. Can one user be given view-only access to a record and another user permission to act on it?
3. Can temporary permissions be given to the person covering for a manager on leave?
4. Is every permission granted and withdrawn recorded, so you can see who had which permission and when?
5. Is an audit log kept of document access and actions taken?

C. Mobile use and employee experience

1. Can employees use it from their phone’s browser without downloading an app?
2. Through which channels do notifications reach field and production staff who have no corporate e-mail address?
3. Through which channels are approvals and notifications sent, and from whose account?
4. What does a new employee see at first login? How are user training and help content provided?
5. Can you show the demo on a phone? Can the forms be filled in comfortably on a small screen?

D. Integration and scope

1. Is there a ready-made integration with our ERP, time and attendance and payroll systems? If not, how is the data flow designed and who is responsible?
2. Which data can we export (for example as XLSX) and in which formats can we import?
3. Do we buy modules one by one or as a single package? Can we add modules as our needs grow?
4. How do we transfer our existing Excel data (employee list, leave balances) during the initial setup?
5. If we need a process specific to us, how are scope and changes managed?

E. Support and growth

1. How is support provided after setup: through which channel, with what scope and with what approach to response times? We want this in writing.
2. Is a new module added to the same user and permission structure, or does it need a separate installation?
3. How are updates done? Can they be applied without interrupting work?
4. Is it possible to start with a single process and a small scope?
5. Do we manage the system in day-to-day operation ourselves, or do we have to go to the vendor for every change?

How do you evaluate the answers?

Avoid two mistakes when scoring. The first is giving every area equal weight: for a company with sensitive data, hosting and permissions should count for more; for a company working in shifts, mobile use should. The second is listening to answers only from the sales team. Evaluate technical questions with your IT team and process questions with HR and operations managers; the people who will use the portal should have a voice in the decision.

When does it make sense to stay with Excel and e-mail?

An RFP is not always necessary. In a company with few employees, a single office and simple processes, a spreadsheet for leave and an e-mail list for announcements may be enough; buying a separate portal would then add an unnecessary burden. These signs show it is time to choose: approvals get lost in e-mail chains, the same information is kept in several spreadsheets, people who do not need it can access sensitive data, and data is compiled by hand whenever management asks for a report. You can prepare the comparison table in Excel too; what matters is that the answers are in writing and everyone is asked the same questions.

How does KurumsalPortal measure up against these criteria?

You can apply the list above to our own product too. YazSis KurumsalPortal runs on the customer’s own server and data is not sent to a third-party cloud; standard cPanel hosting is enough, and the system runs on PHP and MySQL. Employees use it from their phone’s browser without installing an app. In the Menu & Authorization Management module, permissions are defined at role, department and user level, view and action permissions are granted separately, temporary access can be defined and every permission change is recorded. Role-based data scope, masking of sensitive fields, document access logs and audit logs help you set up a process focused on KVKK, Turkey’s personal data protection law.

To adapt the question list to your own company and explore the 33-module structure, take a look at the KurumsalPortal page.