Customer Relationship and Internal Collaboration Platform

This platform supported customer management and internal collaboration. It went beyond customer and contact records: sales opportunities, daily activity, business travel, project logs, expense approval, and calendars had to work together. Managers needed a coherent view of customer progress, while each employee could see only the data within their responsibility.

The challenge was not the number of forms. It was turning dispersed employee activity into a traceable workflow that continued to move each customer relationship forward.

Role and key responsibilities

I contributed to module design, development, and maintenance, focusing on:

• defining the relationships among customers, contacts, opportunities, projects, activities, and travel to reduce fragmented and duplicate records;
• modelling activity expenses, travel requests, issue follow-up, and project logs as stateful business objects with clear ownership;
• applying menu, function, and staff-scope permissions so both page access and record visibility were controlled;
• developing business functions, reporting, attachments, and Word/Excel export within a layered Java Web architecture;
• reconciling documentation, database structure, and actual business behaviour so maintenance changes preserved existing workflows.

From customer records to a collaboration loop

A customer record was the starting point, but the surrounding context created the value. An opportunity could lead to activities and a project. A business trip could record participants, findings, and follow-up actions. Project logs continuously captured delivery progress.

Managers therefore saw more than a static customer table: they could understand the current stage, owner, recent activity, and unresolved issues. Front-line employees no longer had to keep essential context across personal documents, email, and verbal updates.

Data-permission design

Record visibility is one of the most underestimated parts of an enterprise collaboration system. A department head, project member, and individual employee may use the same page but should not see the same records. Menu-only permission still allows data leakage through search or export.

I combined organisation, role, function permission, and controllable staff scope. Search, detail, and export operations all filtered results against the current user's data scope. Permission became part of the business service rather than a button hidden in the browser.

This balanced collaboration with isolation. Managers could review progress across staff, while individual users worked only with customers and tasks inside their responsibility.

Engineering implementation and trade-offs

The system used a layered JSP, Struts 2, Spring, Hibernate/JDBC, and MySQL architecture. The interface handled interaction, the service layer coordinated transactions and permissions, and the data layer supported both regular operations and complex reporting. This structure enabled rapid delivery and clear division across customer, activity, travel, and project modules.

During maintenance, I kept business rules separate from presentation concerns. Customer ownership, approval state, and staff scope were decided on the server; bulk export and attachment access received their own authorisation and resource controls. This reduced inconsistent page logic and made faults easier to locate.

Project value

The platform expanded customer management from contact storage into a collaboration system spanning opportunities, activity, projects, and internal approval. My work centred on domain relationships, workflow state, data permission, and module implementation. It established a lasting architectural principle for my later enterprise work: business objects, organisational responsibility, and permission boundaries must be designed together.