Mohammadreza Talebi

Fargah Operations

A connected operating model unifying public presence, CRM, project handoffs, managed software access, and auditable internal workflows.

Explore the project

By Mohammadreza Talebi · 6 min read

Fargah Operations
Architecture and material-led homepage · Live website capture
Year
2026
Role
Product systems / Development
Scope
Web · CRM · Automation
Status
Ongoing

The project, in context

Fargah's operations work follows an architectural project beyond the public website. I have been designing and developing the CRM, sales-to-design handoff, project dossiers, controlled files and team reporting around the way the business actually works. It is an ongoing system: public enquiries begin the journey, while internal roles, responsibilities and recorded decisions give the team a shared view of what should happen next.

Keeping the project understandable between teams

An architectural project is not a straight sequence of cards. Information can arrive late, a brief can change, design may pause and the project may return to sales. The person creating a dossier is not always the person designing, detailing or reviewing it. I needed to make those transitions understandable while keeping a record of responsibility, reasons and the material available at each point.

The same dossier holds different kinds of information: customer files, working designs, contracts and final deliveries. Different roles need different access. Reports also have to distinguish time spent, completed work and a request to move to another phase. A system that treats all those actions as one generic note can look complete while hiding the questions the team needs answered.

A dossier that carries context forward

I organised work around the customer and project dossier. Sales can create and complete the initial record; the handoff checks required context and records its transition into design. The workflow recognises rough work, design, waiting states, contract and detailing stages, with responsibilities and permitted transitions represented explicitly. A return or pause has a reason rather than simply disappearing from the active list.

For the working team, I built assigned-project views, daily reports, comments, file upload and checklists. Managers have a broader view of phase and reporting information; each contributor sees the work and file categories relevant to their role. The public website remains the entry point, while protected internal pages continue the operational journey. Other software and licensing interfaces are part of the wider programme rather than a claim that every module is already one finished product.

What I built

The parts that make this project useful in day-to-day work.

  1. Enquiry becomes a dossier

    Requests from the public site become lead records that can carry customer details, source, ownership and project information. The sales workspace can expand that initial context into a project without losing the connection to the original customer.

  2. A defined sales handoff

    The handoff considers customer identity, contact, project information and file categories. Missing information can be made visible, and permitted exceptions are role-dependent. Returning a project also records a reason and checks its current phase to avoid an out-of-date transition.

  3. Files with relevant access

    Documents are grouped by purpose, such as customer material, working files, contracts and final outputs. Access depends on role, assignment and category. The file pipeline includes private storage support and a direct-upload path whose availability is controlled by configuration.

  4. Daily work and revision history

    A contributor can record daily work in the context of an assigned project. Reports, comments, completion requests, stop reasons and design revision rounds are distinct records, making it possible to read what happened without treating every entry as a finished deliverable.

  5. Phase-specific checklists

    Design and detailing checklists bring required tasks into the project dossier. Their visibility and editing permissions follow role and phase, while progress is calculated from the actual checklist state rather than a manually typed completion claim.

  6. A team view of responsibility

    Managers can inspect project phases and period-based reports; contributors have personal workspaces and assigned views. Jalali date handling, notices and team reporting patterns make the interface fit the team's day-to-day reading and review habits.

From structure to release

  1. Follow the actual handoffs

    I traced what sales, design, detailing and management each need to send, receive or approve. Responsibilities and file requirements became design inputs before the dashboard layout was settled.

  2. Represent exceptions explicitly

    I built the workflow around recorded transitions, incomplete dossiers, role-specific actions and revision history. The design accounts for work returning to an earlier stage rather than assuming every project moves forward without interruption.

  3. Refine with each working role

    The programme evolves through focused changes to workspaces, dossier access, reporting and mobile file handling. Keeping these changes within a shared project model helps the system grow without turning each department into a separate application.

Delivery and current scope

  • A CRM organised around customer records, projects, phases and assigned responsibility.
  • Sales handoff, return-to-sales and recorded changes in the design workflow.
  • Role-aware documents, working-file categories and project reporting.
  • Design and detailing checklists, personal workspaces and managerial reporting views.
  • An ongoing foundation for the wider Fargah software and operational programme.

Questions about this project

How is this different from the Fargah website project?

The website helps visitors understand the company and begin an enquiry. Operations covers the team's work after that point: customer dossiers, assignments, documents, phase changes and reporting. They are related parts of the journey, with different users and access boundaries.

Can internal screens be explored publicly?

The operational workspace contains customer and team information and is intended for authorised roles. This case study explains the workflow without publishing real customer records or private working documents.

Is the whole operations system finished?

It is an ongoing programme. The CRM and project workflow have concrete implemented modules, while wider integrations and workspace improvements continue to develop. The case study distinguishes those working capabilities from the broader direction.

Have a similar project in mind?

Tell me what you need to build and where the current experience falls short.

Start a conversation+989304330645
Next projectFargah Design Toolkit