Access Trust Insurance public homepage
The public ATI homepage. Administrative interfaces and customer information are intentionally not shown.

My contribution

I worked on ATI at Achour Holding with Tayseer Laz, who primarily worked on the public-facing website. I owned the backend, the content CMS, the client, agent, and admin portals, and production deployment.

That scope connected the public website to the operational paths behind it: managing website content, receiving insurance requests and documents, routing work to staff, and giving each role an appropriate interface for following the request.

One platform, four working surfaces

  • Public websiteManaged content and service entry points

    The content CMS supports the public information layer, while forms and calls to action lead into the appropriate service workflows.

  • Client portalRequests, documents, and status

    Clients can move beyond a contact form into structured proposal, claim, complaint, document, and meeting journeys.

  • Agent portalAssigned work and follow-up

    Agents receive routed work and the context needed to continue a request without turning the public website into an internal dashboard.

  • Admin portalOversight and configuration

    Administrators manage content, users, assignments, submissions, and the operational settings that support the public and authenticated experiences.

Technical delivery

The central delivery problem was not adding isolated forms. It was carrying a request from a public entry point into authenticated, role-specific follow-up while preserving the information and documents needed by the people handling it.

Operational workflow

  1. 01 · EnterStart from the right service

    A visitor begins with a proposal, claim, complaint, meeting, or information request through the public site or client portal.

  2. 02 · CaptureCollect structured context

    The backend receives the request, relevant answers, and permitted supporting documents instead of reducing every journey to an unstructured message.

  3. 03 · RouteAssign operational ownership

    The workflow directs the request to the appropriate staff path and keeps its status available to the roles responsible for follow-up.

  4. 04 · ContinueWork through role-specific portals

    Clients, agents, and administrators see different interfaces around the same service journey, with each surface focused on its own responsibilities.

  5. 05 · OperateDeploy and maintain the full path

    I handled production deployment and continued fixing the application around real content, email, storage, workflow, and release needs.

Delivery ownership

Backend and workflow layer
I implemented the server-side application behind authentication, submissions, routing, documents, email, and the shared operational state used by the portals.
CMS and portals
I built the content-management system and the client, agent, and admin experiences rather than treating the public website as the whole product.
Production deployment
I owned the deployment path and the production fixes required to keep the public website and authenticated workflows operating together.