EspoCRM for agencies and professional services firms

How EspoCRM fits agencies and professional services firms

Agencies and professional services firms run client work between two systems. The CRM holds the accounts, contacts and opportunities that get a client signed, and the project tool holds the scope, tasks and deadlines that deliver it. The information that matters most, such as the agreed scope, the commercial terms, the decision makers and the promises made during selling, usually gets lost in the move from one to the other. In EspoCRM, the fit for a firm like this depends on the Project Management extension, which links accounts and opportunities to projects so that the won deal and the delivery work share one record trail. Before committing, confirm with the vendor how the extension is licensed and whether it is included in your edition, since EspoCRM's free open-source edition and its cloud plans are priced and packaged differently.

Once the link exists, the roles change in practice. Sales keeps ownership of the opportunity until it closes, then hands the account to delivery with the project already created from it, so the seller no longer re-keys scope into a second tool. Delivery leads work from projects with members, roles, tasks and milestones, and they can see the originating account and opportunity without asking sales for context. Account leads get one view across open opportunities and active projects for the same client, which is the view most often missing when a second engagement is sold to an existing customer. Decide early who may move an opportunity to won, who creates the project, and who may change the client's details, because these permissions determine whether the handoff is trusted or worked around. Test the setup with one closed deal from your own pipeline before rolling it out.

What agency and firm requirements mean for the build

This table maps common agency and professional services requirements to the supplied EspoCRM facts and to what each one means for configuration. Read each row as a question to answer before the build starts, then check the source named in the last column. Several rows depend on the Advanced Pack or the Project Management extension, so confirm edition and extension scope with your partner before you commit.

Requirement	What it means for configuration	Supplied EspoCRM fact	Source
Won deal to project handoff	Opportunities feed projects in the Project Management extension, so the won-deal trigger and the project record must be designed together	Projects provide members and roles, tasks, milestones, groups and project cloning	EspoCRM: Projects documentation
Staffing by role	Define project roles and assign members per project rather than relying on one account owner per engagement	Projects support members with roles	EspoCRM: Projects documentation
Milestone and status visibility for clients	Decide which milestones and updates the client sees and post them through the project stream instead of ad hoc email	Project stream posts updates; milestones are a project object	EspoCRM: Projects documentation
Plan, board and Gantt views for delivery leads	Choose which views account managers and delivery leads use, and confirm how each view reads task dates	Plan, board and Gantt views are provided	EspoCRM: Projects documentation
Billable meeting history	Meetings should link to the account, opportunity and project so the history is traceable; confirm meeting booking scope with your partner	Meetings are a core CRM record type; the Advanced Pack is not required for basic meeting records	EspoCRM: Projects documentation (confirm meeting linkage in your instance)
Restricted client access	Clients need portal access limited to their own records, so portal roles must be designed separately from internal roles	Portal roles and teams control record scope; confirm portal visibility for projects in your version	EspoCRM: Security documentation (confirm portal scope)
Identity through the firm's directory	Sign-in can use the firm's identity provider through OpenID Connect, with optional user creation and group-to-team mapping	OIDC supported since 7.3, with group mapping to teams; EspoCRM 2FA is not compatible with OIDC	EspoCRM: OIDC docs
Directory-based access without OIDC	If the directory is Active Directory or OpenLDAP, LDAP authentication is an option to evaluate against your sign-in design	LDAP authentication including Active Directory and OpenLDAP is documented	EspoCRM: Security documentation (confirm LDAP details)

Which EspoCRM modules and settings matter for client work

Client work in EspoCRM depends on a handful of decisions made early: how accounts and opportunities are modeled, how won deals hand off to delivery, and how much of the project record clients can see. Each card below is a configuration choice with a trade-off attached, so confirm the answers with your delivery and sales leads before building.

Project Management extension scope

The Project Management extension gives you projects with members and roles, tasks, milestones and groups. Decide first whether every engagement becomes a project or only fixed-fee and multi-phase work, because that choice determines how much of your pipeline turns into delivery records. Map roles to the people who actually approve, staff and bill the work, and check which project fields clients or contractors can see before you grant access.

Plan, board and Gantt views

Plan, board and Gantt views show the same tasks and milestones in different ways. Agree on which view your project managers will use to run weekly delivery and which one account leads will use for client timelines, then set the default view and the fields shown on each. Confirm that task dates and dependencies are entered consistently, since a Gantt view is only as accurate as the data behind it.

Account and opportunity structure

Accounts hold the client organization, while opportunities hold the scoped work you sell. Decide whether one account can carry several opportunities and projects, and where recurring retainers or change requests are recorded. Standardize stage names and required fields on opportunities, such as scope summary and expected delivery owner, because the project created from a won deal inherits what was captured at that point.

Won-opportunity automation with the Advanced Pack

A workflow can create or update a project when an opportunity reaches a won stage, which removes manual re-keying between sales and delivery. Workflows and BPM come from the Advanced Pack, which is included in all EspoCRM Cloud plans. Before you build the rule, decide which fields copy across, who is assigned to the new project, and what happens to a project when the deal is later reopened or reduced in scope.

Client portal access and project stream

The project stream is where updates are posted, so it is the natural channel for client-facing progress notes. Set portal roles so clients see only their own accounts, projects and stream posts, and keep internal discussion, margin data and time notes out of their view. Test portal access with a sample client user before launch, and review it whenever a project is cloned or a new contact is added to an account.

How a won opportunity becomes a project

The handoff starts the moment an opportunity is marked won, and the first decision is who owns the project that follows. In most agencies that is a delivery lead rather than the salesperson who closed the deal, so the owner field, the project members and the role each person holds should be settled before anyone creates a project. The Project Management extension gives each project its own members and roles, so decide which roles the account owner keeps (for example, visibility into the project stream) and which the delivery lead needs to plan and assign tasks. Confirm in the extension documentation how a project is linked to the account or opportunity it came from, and whether that link is set by hand or by an automated step. Do not assume the link exists by default.

Next, check which fields actually carry over. Nothing should be assumed to copy from the account or opportunity into the project, including contract value, close date, primary contact and billing contact. Build a test with a sample won opportunity in a staging instance and inspect what appears on the project. Any value that does not carry over needs a manual step, a formula or an automated action. If you plan to create projects automatically when an opportunity reaches the won stage, the Advanced Pack's Workflows and Business Process Management features are the likely route, and the Advanced Pack documentation should confirm which actions can create a project and how they set members and roles. Included in all EspoCRM Cloud plans, that pack is not a substitute for testing your own setup.

Cloning is where setup time is saved, but only after you know what a clone copies. Keep one maintained template project for each service line, with standard milestones, task groups, a board layout and the internal roles your delivery team uses. Before relying on it, confirm in the project documentation whether cloning copies tasks, milestones, groups and members, whether it shifts dates to the new start date, and whether it copies project stream posts or client-specific details that should never be reused. Clean templates reduce rework, but a template that carries the previous client's data creates a confidentiality problem. Ask your implementation partner to include template maintenance in the written scope.

What sales, delivery and account leads each need from the setup

Sales works mainly in accounts, contacts and opportunities. Their setup starts with the opportunity layout: the fields that qualify a deal, the stage order and the values that must be filled before a deal can move forward. Because opportunities later feed projects, the fields captured at close (scope, value, start date, billing contact) should be defined now, not patched in after the first project is created.

Opportunity layout: Decide which fields are required at each stage and which are read-only once a deal is won.
Sales team: Assign sellers to a team so that they see their own accounts and pipeline without seeing unrelated client records.
Lead ownership: Agree who owns an account after the deal closes, since that owner often becomes the account lead.
Handover fields: Add the fields the delivery team needs, such as project type or contract reference, and mark them as mandatory at won.
Reports on pipeline: Confirm which pipeline reports sales managers need, since report access depends on the Advanced Pack.

Check with sales leads which fields they will refuse to fill in, because unused required fields quickly turn into placeholder data.

Client portal and access decisions that need an owner

Giving clients a portal turns your CRM into an external surface, so every access decision needs a named owner before go-live. The cards below cover the decisions that most often go wrong: what clients can see, what stays internal, which API users exist, and how sign-in is protected. Each one ties back to EspoCRM's documented security guidance and names what your firm must confirm in its own environment.

Scoping portal roles to client projects

Portal users are limited by portal roles, and the role defines which accounts, projects, tasks and streams a client can open. Test the role with a sample client account that has a real project and a neighboring client's project, and confirm that the second project cannot be reached through list views, links, search or the project stream. Project-level membership and team assignments also affect what a portal user sees, so review them alongside the role. Ask who approves any change to portal role permissions.

Keeping internal notes internal

Project streams and records often hold margin notes, scope disputes, staffing comments and draft estimates that were never meant for clients. Before opening a portal, audit which fields, notes and stream posts are visible to portal roles, and decide which content stays with internal users only. Confirm the stream behavior for updates you post on behalf of the team, since a status update written for the internal team may read differently to a client. Agree on a review step for anything published to the stream.

Limiting API user permissions

The REST API authenticates through dedicated API users with their own role-based permissions, so an integration can see more than a client ever should if its user is over-scoped. Create one API user per integration, give it only the entities and fields it needs, and avoid reusing an admin or a personal account. The security guidance favors HMAC over basic authentication and describes basic authentication as not recommended. Confirm which integrations exist, who owns each API user, and how keys are rotated.

Setting password and two-factor policy

Portal accounts are often created by staff and then used rarely, which makes weak passwords and forgotten recovery paths common. The security guidance recommends enforcing a password policy, requiring two-factor authentication, and limiting auth token lifetime. If you use OpenID Connect sign-in, note that EspoCRM's own 2FA is not compatible with OIDC, so the identity provider must carry the second factor. Confirm which factor each user type uses and who handles lockouts.

Restricting admin access and recovery

Admin accounts can change portal roles, API users and sign-in settings, so they should not be used for daily project work. The security guidance recommends avoiding admin accounts for daily use, disabling password recovery for admins, and restricting access by IP address. Decide which named people hold admin rights, where admin logins are allowed from, and how an admin account is recovered if the only holder leaves. Write the answers down before go-live.

Confirming controls in your own environment

The supplied guidance describes what EspoCRM can enforce, but your firm still has to confirm how it is configured in your deployment. Check the portal URL, the IP restrictions in front of it, the identity provider settings, and whether your version still disables UI upgrades by default. Record who owns each control, how it is tested after changes, and which client contracts require notice before a portal opens to their staff. A test pass with a client-like account is the most direct evidence.

Rollout phases for an agency or firm

The sequence moves from agreeing the workflow map to a piloted, migrated and connected system, so each phase proves one layer before the next depends on it. Each step closes with a check that the team can verify before moving on.

Map the client workflow and project template
Walk through how a client moves from first contact to signed work, through delivery and into renewal or close. Agree the stages, the roles on each project (such as account lead, delivery lead and client contact), and the standard task and milestone list a typical engagement needs. Partners and delivery leads sign off on this map, and DeployOpen documents it as the reference for every later configuration choice. Done when the stages, roles and template tasks are written down and approved by the people who run client work.
Configure accounts, contacts and opportunities
Set up the account, contact and opportunity layouts, stage lists, teams and roles so that sales activity reflects the agreed map. Decide which fields are required at each stage and which are read-only once work starts, and use the Entity Manager for any custom fields the firm needs, such as engagement type or billing model. Check the result by creating a few test accounts and opportunities as different roles and confirming each user sees only what their role allows. Done when the sales pipeline runs end to end in a test instance and the field rules match the workflow map.
Enable Project Management and link won work to projects
Install the Project Management extension and decide how a won opportunity creates or links to a project, including which project members, roles, milestones and groups are copied across. Set up the board, plan and Gantt views that delivery leads will use, and test project cloning against the standard template so that repeat engagements start from a known structure. The project stream should be configured so that status updates are posted where the team and the client contact will look for them. Done when a test opportunity produces a project with the expected members and tasks and the views show the same data.
Pilot with one delivery team
Run the configured process with one live delivery team for a short, agreed period, using real but low-risk engagements. Collect feedback on missing fields, confusing stages, slow views and any step where people fall back to spreadsheets or email. Record each change in a list with an owner, then apply only the changes the team agrees are needed before the wider rollout. Done when the pilot team has closed its engagements in the system, the change list is resolved or deferred with a reason, and the delivery lead confirms the process is usable.
Import existing client and project data by CSV
Migrate accounts, contacts and open opportunities from the current tools using the CSV import. Map each source column to a field, choose the mode (Create Only, Create and Update or Update Only) for each object, and set duplicate matching on fields that identify a client reliably, such as a registration number or a normalized email address, not on the company name alone. Run a small sample first, check the results, and use the revert option if the mapping was wrong. Large files can run through cron so they do not time out. Done when record counts match the source, duplicates are reviewed and the sample rows display correctly in the layouts.
Extend to portal clients and enforce SSO
Once internal data is clean, open the client portal to selected client contacts with a portal role that limits them to their own accounts, projects and shared streams. Connect staff sign-in through OpenID Connect or LDAP, decide whether users are created on first login, and map identity provider groups to EspoCRM teams. Confirm that the fallback login method and the security baseline in the EspoCRM security documentation are in place, including 2FA for internal users and no daily admin work. Done when a portal test user sees only their own records, a staff user signs in through the identity provider, and the security review is recorded.

Moving client and project data out of spreadsheets or another CRM

Import accounts first, then contacts linked to those accounts, then opportunities, because each later file depends on records that already exist. The CSV import offers three modes: Create Only adds new records, Create and Update adds new records and changes existing ones, and Update Only changes existing records and skips new ones. For accounts, a re-run in Create and Update mode is the usual way to correct names or owners without creating duplicates, provided duplicate matching is set on a stable field such as an external client ID or a normalized company name. For contacts and opportunities, map each column to a field deliberately, including the account relationship and the assigned user. Confirm in your EspoCRM version how link fields are matched during import, since a mismatched account name can leave contacts unattached. The EspoCRM import documentation describes the mapping and matching options in detail.

Clean the source files before the first import. Remove duplicate client rows, standardize company names and date formats, confirm that every opportunity has an owner who exists as a user in EspoCRM, and agree which status values map to your pipeline stages. Run the first import against a non-production instance with a small sample, check the results against the source, then use the revert function on that import to confirm you can undo a bad run before loading the full dataset. Large files should run through the cron-driven idle execution so the web interface stays responsive, which means confirming that the scheduled job runs on the test server first. Record the import settings used for each file so the production run can be repeated exactly.

Decide what happens to historical projects and time records before any project data is loaded. Closed client work can be kept as archived opportunities for reporting, or moved into the Project Management extension as projects with members, tasks and milestones, which adds effort because each project needs its team and task structure mapped. Time records are a separate decision: confirm with the vendor whether the extension stores time entries and, if it does, how they relate to projects and users before you plan a migration. If time data stays in the previous system, agree who retains read access and for how long. These choices determine how much cleanup the import needs, so settle them with finance and delivery leads before the first trial run.

Client data and confidentiality considerations

A consultancy's EspoCRM holds client contracts, scope notes and personal details of client contacts, often across several engagements with different confidentiality terms. The cards below cover the access, authentication and data handling choices that decide who can see what, and what the firm should confirm before going live.

Separate client records by team

Engagement data is only as confidential as the access model behind it. Use EspoCRM teams and roles so that account managers, delivery leads and finance staff see only the accounts and projects they work on. Test the model with a non-admin user before go-live, since administrators see everything by design. Confirm that project records inherit the same restriction as the opportunity that created them.

Enforce strong sign-in

The security documentation recommends a password policy and two-factor authentication for all users. Because EspoCRM's own 2FA is not compatible with OIDC sign-in, a firm using single sign-on must decide where second-factor checks happen and confirm this with its identity provider setup. Document the chosen approach so auditors can trace it.

Keep admin work separate

Administrators can change roles, export data and reset access. The documentation recommends not using admin accounts for daily work. Give the firm's system owner a separate admin account, disable password recovery for admins, and keep a short, named list of who holds admin rights. Review that list whenever staff change roles.

Restrict access by network

Client data often needs to be reachable only from office networks or approved VPN ranges. The security guidance covers restricting access by IP address. Ask the delivery team which locations and devices need access, then test that blocked networks cannot reach the login page or API. Remember that API users need their own network rules.

Set session and token lifetimes

Authentication tokens that stay valid for long periods extend the damage of a stolen laptop or an unattended browser. The security documentation recommends limiting token lifetime. Agree a lifetime with the firm's security owner, then align it with the rules for shared offices and client-site work. Revisit it when a client contract adds stricter terms.

Confirm compliance readiness with the firm

EspoCRM's features and settings can support a firm's confidentiality and personal data commitments, but they do not make the firm compliant. Map each client agreement's obligations to a configured control, record the evidence, and let the firm and its auditors decide whether it meets their requirements. DeployOpen prepares controls and evidence; it does not issue audit reports or certifications.

What agencies and firms ask before hiring a partner for EspoCRM

What drives the cost of an EspoCRM setup for a professional services firm?

The main drivers are how many users the firm runs, which hosting model it chooses, and how much configuration sits on top of the base product. EspoCRM Cloud is priced per user per month, so headcount and the plan tier set the recurring subscription. The EspoCRM pricing page lists Basic at 15 US dollars per user per month with a minimum of 3 users, Enterprise at 25 dollars with a minimum of 5, and Ultimate at 69 dollars with a minimum of 10. The Advanced Pack is included in all cloud plans. For self-hosting, the software itself is free to download, so the costs shift to servers, backups, upgrades and the partner's work on scope. Ask for a quote that separates one-time implementation from recurring hosting, licenses and support.

Is the Advanced Pack included, and do we need it for project work?

The Advanced Pack is included in all EspoCRM Cloud plans, according to the EspoCRM pricing page. It provides reports, Business Process Management and workflows. The Project Management extension is a separate official extension that adds projects, tasks, milestones, plan, board and Gantt views, so confirm with the vendor which extensions your chosen edition and hosting model include before you assume the project module is covered. For self-hosted instances, the Advanced Pack is an add-on that must be installed and licensed separately, so check its current terms on the Advanced Pack page before budgeting.

How long does it take to get a first client project running in EspoCRM?

The time to a first working project depends on how much of the firm's sales-to-delivery path must be modeled before anyone uses it. A basic setup that links accounts and opportunities to projects is usually shorter than one that also needs custom fields, approval steps, client portal access and a data import. No duration is fixed in this page. Ask a partner to break the timeline into phases: process mapping, configuration in a test instance, a pilot with one team, then rollout. A written scope should state which phases are included and what each one depends on from your side.

What must our firm provide before implementation starts?

Most delays come from missing inputs rather than from the software. Prepare the following before the first workshop:

Process maps for how deals close, how work is scoped, staffed and delivered, and how invoices and renewals are handled
Templates for project plans, task lists, milestone sets and client update messages
A sample of client and contact data, with its quality issues noted, for the migration plan
Named decision owners for each area, who can approve field, stage and permission changes
Access to your identity provider and mail systems if single sign-on or email is in scope

Can our own team configure the Project Management extension without a partner?

Yes, a team with an administrator who understands the firm's processes can configure projects, tasks, milestones and views in a test instance. EspoCRM's own documentation describes members and roles, boards, plan and Gantt views, project cloning and the project stream. The harder questions are usually design ones: how opportunities hand off to projects, which fields carry billing or capacity data, who can see which clients, and how changes are tested before they reach live users. A partner adds most value on those decisions and on the audit trail of changes. Your team can take on the routine configuration once the design is agreed.

What does a self-hosted EspoCRM instance need from our infrastructure team?

Plan for a PHP runtime within the supported range, MySQL 8.0 or newer, MariaDB 10.6 or newer, or PostgreSQL 15, served by Apache, Nginx or IIS. Background jobs need cron or a scheduled task, which often gets missed in handover. The installation script for Ubuntu, Debian and Linux Mint deploys a Docker-based stack with Nginx and MariaDB and includes a command.sh utility for backups, restores and upgrades. Your team also needs a backup schedule, TLS certificates and a patch routine. Confirm the exact server requirements against the server configuration docs for the release you plan to run.

How do we connect EspoCRM to our identity provider and keep access tight?

EspoCRM supports OpenID Connect sign-in since version 7.3, with optional user creation on first login and mapping of identity provider groups to EspoCRM teams. It also documents LDAP, including Active Directory and OpenLDAP. Its own two-factor authentication is not compatible with OIDC, so decide where MFA is enforced before you switch sign-in. The security documentation also recommends a password policy, limited token lifetime, IP restrictions and avoiding admin accounts for daily work. Ask the partner to show the group-to-team mapping for each client-facing role before go-live. The OIDC docs describe the settings.

What happens to our data when we move from spreadsheets or another CRM?

Migration scope depends on the source data and how much history must survive. EspoCRM's CSV import supports Create Only, Create and Update, and Update Only modes, field mapping, duplicate matching on chosen fields, and reverting imported records. Large files can run through cron. Decide early which records move, which are archived, and which are rebuilt by hand, such as active projects with open tasks. Test each import in a non-production instance and compare record counts and key fields before any client sees the data. The import docs cover the mechanics.

How DeployOpen scopes and delivers an agency or firm setup

DeployOpen plans, implements, customizes, integrates, documents and supports self-hosted open-source platforms inside your own infrastructure. For agencies and professional services firms, that means turning client work into a written scope, building EspoCRM around accounts, opportunities and projects, and handing over a system your team can run.

How we scope

Map how your firm moves from opportunity to signed work to delivered project, and where each handoff happens.
Agree in writing which entities, layouts, project templates, portal access and integrations are in scope before work starts.
Confirm the hosting target, identity provider and extension set so the quote reflects your environment and not a generic setup.

How we build

Configure accounts, opportunities and projects in the Project Management extension, with members, roles and milestones modeled on your delivery process.
Set up board, plan and Gantt views for project leads, and test client portal access against the roles you defined.
Test imports, permissions and project stream posting with representative data from your own pipeline before go-live.

How we hand over

Deliver written documentation of entity design, roles, workflows, integrations and the configuration choices behind them.
Walk administrators through project templates, cloning, permissions and routine maintenance tasks on your own instance.
Provide a backup and restore routine and an upgrade plan that covers extensions and PHP versions before the next major release.

How we support

Support after go-live can be agreed as a retainer covering fixes, extension updates and changes to project workflows.
Upgrades are planned against your customizations and installed extensions, with testing on a copy before production changes.
Ask any partner which EspoCRM version, extensions and hosting model their support covers, and confirm it in the written scope.