Evaluating a Customer Portal Developer Based on 8 Criteria

A client requests an invoice copy via email, inquires about the order status over the phone, and another colleague retrieves data from Excel related to the contract. Meanwhile, the customer asks: why can't I see all this in one place? In such a situation, evaluating a customer portal developer is not primarily a design or programming issue. It is about deciding whether the company is building a new, sustainable operational channel or merely placing a digital interface in front of existing internal chaos.

A well-designed portal can reduce repetitive inquiries, improve customer awareness, and make internal work more accurate. However, a poorly prepared portal can generate new exception handling, parallel data, and support load. Therefore, when choosing a developer, it is crucial to assess whether the partner understands how information truly flows between sales, customer service, warehouse, finance, and the customer.

Why aren't the visual design and hourly rate enough?

In portals, the interface is only the part that the customer sees. The operational risk is typically behind it: which system is the data owner, when is an order status updated, who can see an invoice or contract, and what happens if an integration is temporarily unavailable.

A lower development offer can sometimes be a good business decision. This is the case if the process is simple, requires connection to few systems, and the company knows its requirements precisely. However, if the portal needs to display data from ERP, CRM, webshop, warehouse system, or custom records, the seemingly cheap start can lead to expensive modifications later.

The right partner does not claim that an application should be built immediately for every request. First, they examine whether the customer truly needs the given function and whether the internal process is clear enough to be digitalized.

Evaluating a customer portal developer with 8 business questions

1. Does the developer ask about the process first?

It is a warning sign if the first meeting is solely about menu items, colors, and login screens. These are necessary details but not starting points. An experienced partner asks: what customer inquiries do you want to reduce, what data should the customer access independently, and which internal steps are triggered by a request submitted on the portal.

For example, if a customer records a complaint, creating a form is not enough. It is essential to know who receives the case, what data is needed for investigation, how the status can be tracked, and in which cases human decision is required. This reveals whether it is a portal function, an internal workflow, or both.

2. Does it uncover where the data comes from?

The "order status" often means multiple systems. According to the webshop, the order is paid, the enterprise resource planning system says it is being processed, the warehouse indicates it is waiting for picking, and the courier service shows it has already been handed over. The developer must not only query data but also jointly determine what each status means for the customer.

Ask if a data source map and responsibility model are being prepared. Which system is the primary record? How often are the data synchronized? Who investigates discrepancies? These are not technical trivialities but conditions for customer trust.

3. Can it distinguish between standard and unique needs?

Not every process that provides a competitive advantage requires unique software. Sometimes an existing system's customer interface would be suitable, but it is poorly configured or not connected to the necessary data sources. Other times, the company's special pricing, service process, or partner authorization system justifies a custom portal.

A good developer does not try to apply a single tool to every problem. They clearly explain which elements should be solved with standard components and where custom development is justified. This later affects modifiability, cost, and operational risk.

4. Does it clarify permissions and business exceptions?

A B2B customer portal often does not have a single user. There can be a purchaser, financial contact, site manager, and external partner on the same customer side. Not all of them can see the same prices, invoices, contracts, or service data.

When evaluating the developer, see how they handle roles, approval rules, and exceptional cases. What happens during a corporate merger? Who can request a new user? What control is there if a customer has multiple legal entities? A well-functioning portal is not secure because it has a password, but because the business rules of access are clear and verifiable.

5. Does it have a method for validating requirements?

Many projects falter because the client and developer use the same term but mean different things. "Order modification" can mean changing the quantity, rewriting the delivery address, cancellation, credit limit check, or a combination of these.

Ask how assumptions become accepted operational rules. Do they use flowcharts, specific business examples, prototypes, or testable acceptance criteria? The goal is not the amount of documentation but to uncover misunderstandings before development begins.

6. Does it plan for handover, error handling, and operation time?

A portal does not become a complete system on the go-live day. User questions, permission issues, new business needs, and external system updates will continue to arise. Without designated responsibility, monitoring, logging, and change management, the company will soon be forced back to manual checks.

It is worth specifically asking about the support model. Who monitors integration errors? How does the company get notified if incorrect data appears to the customer? Is there a rollback procedure and test environment for changes? Business continuity is not a separate service but part of the development decision.

7. Can it discuss security along with business implications?

Security does not end with the system operating over an encrypted connection. A customer portal can handle business data: order history, prices, financial documents, technical files, or personal data. Unauthorized access is not just a technical incident but can be a contractual, reputational, and even operational issue.

A reliable response is if the developer talks about access management, logging, data retention, backups, and update responsibility together. The details depend on the industry and data sensitivity, but questions cannot be left until the end of the project.

8. Can it define measurable business outcomes?

A "more modern customer experience" is insufficient to guide the project. It is worth recording at the start what change is expected: reducing the number of invoice copy requests, shortening the time for order status reconciliation, improving data accuracy, or making the open service issues more transparent.

Not every benefit is immediately measurable in currency. It is also valuable if the customer service representative spends the morning solving complex issues instead of searching. However, metrics help distinguish real operational improvement from simply getting a new interface for old problems.

What to pay attention to when reading references and offers?

A reference is useful if it shows not only screenshots but also the operational situation solved. How many systems were connected? What kind of authorization model was necessary? How were data quality issues handled? What changed in customer service or internal administration work?

In the offer, look for the boundaries as well. What exactly is included in the development, what is the integration prerequisite, who provides the test data, and what counts as a later change? A vague offer may seem convenient in the short term but causes disputes about responsibility and costs later.

In CGAT's view, the portal is not an independent digital showcase but part of the company's operations. Therefore, before development, it is worth following the path that a customer request and its associated data actually take.

The best next step is often not a developer request for proposal, but selecting five to ten common customer requests. Look at where they start, how many people are involved, which systems they appear in, and where information needs to be manually forwarded today. If this picture is clear, evaluating a customer portal developer becomes a much more informed decision.