A niche store for van and sports car modifications needed an e-commerce engine that could support product changes without requiring a redeploy. The TanosMotorsport case study describes a system that refreshes prices and stock within about two minutes and can serve storefronts in Polish, English and German. It is not a customer portal, but it points to the decision that matters: does repeatable work need a better process, or is email already doing the job well enough?

The situation

TanosMotorsport sells products whose prices and availability can change. The case study describes a reusable e-commerce engine, with a headless content system behind a separate storefront. Product prices and stock can refresh without redeploying the storefront, and the same engine was designed for reuse by other product-driven businesses.

That is a specific operational need: changing product information should not require rebuilding the whole storefront. It is different from a business receiving occasional customer questions by email. A portal would not automatically solve either problem; it would only be useful if its features matched the work people actually need to do.

The decision that mattered

The important choice in the TanosMotorsport case was not “email or portal.” It was how to handle information that changes and needs to reach the storefront reliably. The system was designed around those updates, rather than treating each change as a separate manual rebuild.

For your business, apply the same kind of reasoning to requests. If customers repeatedly need to submit the same information, check progress, send documents or take a familiar action, email may be making them and your staff repeat work. If requests are unusual and need conversation, judgement or negotiation, a portal may add a form and another place to check without making the work simpler.

What that meant for the client

The engine was designed so product prices and stock could refresh within about two minutes without a redeploy. It also supported Polish, English and German storefronts and was intended to be reused for other product-driven businesses. Those are the stated design outcomes; the case study does not claim that the system reduced support emails or that TanosMotorsport introduced a customer portal.

That distinction matters. A relevant case study can show how a business need shaped a software decision, but it cannot prove that the same choice is right for your request process. The useful parallel is narrower: when a recurring task has clear rules and a repeatable shape, software can give that task a more suitable structure. The business case still depends on your customers’ needs and your team’s workload.

What the case does—and doesn’t—show

The case does not show that a portal is better than email. It does show why you should start with the work, not with the idea of having an app or portal. TanosMotorsport needed a way to keep product information current across its storefronts. Your team may instead need to answer varied questions, gather missing details or make decisions that depend on the circumstances.

Map the requests that arrive today. Notice which ones follow the same steps, which details are repeatedly missing, and which updates customers ask for. Then ask whether a portal would remove those points of friction or simply move the conversation from an inbox to a website. If you are preparing to discuss a possible build, our guide to writing a software brief without technical expertise can help you describe the problem before choosing a solution.

When email is still right

Keep handling requests by email when the volume is manageable, each conversation is meaningfully different, and customers benefit from a direct human response. Email is familiar and flexible. It does not require you to design and maintain a new customer-facing service, decide who owns its content, or explain a new process to customers.

It is also a reasonable choice when the real issue is an unclear internal process. A portal will not decide who should answer a request, what information is needed, or when someone should follow up. If those responsibilities are unsettled, make them clear before paying to put them behind a new interface.

What a portal must earn

A portal is worth considering when it gives customers a useful reason to return to the same place: to submit a standard request, see its status, retrieve information or complete a repeatable task. It should also give your staff a better way to handle that work—not just another queue that needs monitoring.

Be honest about the trade-off. A portal takes effort to design around real customer behaviour, maintain as your services change, and support when people get stuck. Some customers may still email, especially for unusual requests. So the goal is not to eliminate email at any cost. It is to make the common path clearer while keeping a sensible route for exceptions.

You do not need to start with a full portal. You can first document the request types and the current handoffs, then decide whether a small self-service area would address a specific, repeated problem. Our software delivery process explains how we approach planning, delivery and ongoing support; the important question for your decision is whether the work is clear enough to justify building at all.

Bottom line

Keep email if requests are manageable and mostly need individual discussion. Consider a portal only when recurring tasks create real friction for customers or staff, and define the task it must improve before scoping features. If you are unsure where that line falls, talk with PixelHorizon about your situation.