How EspoCRM for subscription and SaaS businesses keeps renewals, billing and portal access in one record
When renewal dates, plan changes and payment status live in a billing tool, a spreadsheet and a support desk, nobody sees the full customer at the moment it matters. EspoCRM can hold the subscription lifecycle next to accounts and opportunities, using the Sales Pack for subscriptions and billing plans, the Advanced Pack for reports and workflows, and the official Stripe extension for payment data. Sales sees the plan and its renewal date beside the open expansion opportunity. Customer success sees usage concerns and open cases on the same account. Finance sees which invoices are paid, failed or pending without exporting anything. Support can check whether a customer has portal access and which plan they are on before answering a ticket.
The design work starts with the entities and their links: which record represents a subscription, how a billing plan relates to it, and whether renewals are opportunities that the Advanced Pack's workflows create ahead of the end date. Confirm with your team how the Sales Pack models recurring items and whether its billing plan fields match the terms you actually sell. Decide who owns each status field, since a field that both finance and sales can edit will drift. Plan the scheduled reports that drive renewal outreach, and confirm the report types and schedule options in your installed version before you promise a cadence to customer success.
Because EspoCRM is licensed under AGPL-3.0 and can be self-hosted, the whole build runs in infrastructure you control, including the database that holds payment references and the customer portal. Decide early where the Stripe credentials are stored, which API users may read subscription data, and how portal roles limit what customers see. Check the security settings you will enforce, such as two-factor authentication for staff and IP restrictions for admin access, and test them with a non-production copy of your data. Ask the implementation partner to document each decision in writing so the setup can be reviewed and maintained later.
Which requirements in EspoCRM for subscription and SaaS businesses shape the build
This table maps the requirements a recurring revenue business typically faces onto concrete EspoCRM build decisions. Read each row as a question to settle before configuration starts, with the source telling you where the requirement comes from. The main takeaway is that renewal data, payment reconciliation, customer access and change control need to be designed together, not added after go-live.
| Requirement | Source | What it means for the build |
|---|---|---|
| Renewal visibility | Business requirement; EspoCRM scheduled reports in the Advanced Pack | Model contract term, renewal date and status on a dedicated entity, then use scheduled report emails to surface upcoming renewals to account owners. Confirm the report filters you need before building layouts. |
| Reconciliation with Stripe payments | Business requirement; official Stripe integration | Decide which system is the record for invoice and payment status. Map Stripe customer and subscription identifiers to CRM accounts so finance can match billing events to contracts. Confirm the exact fields the integration syncs in your version. |
| Portal access limits for customers | EspoCRM portal roles and user types | Limit portal users to their own accounts and contracts through portal roles. Test that customers cannot see other accounts, internal notes or pricing that is not meant for them. |
| Processor instructions for customer personal data (GDPR Article 28(3)) | GDPR Article 28(3), EUR-Lex | If you process customer personal data on behalf of your customers, the processor contract must set documented instructions, including for transfers. Keep the CRM configuration, data retention settings and hosting location consistent with those instructions, and confirm them with counsel. |
| Customer switching rights (EU Data Act) | EU Data Act, Regulation (EU) 2023/2854, Articles 23, 25 and 50 | If your service falls within the Act's scope as a data processing service, customers may need to move to another provider or on-premises infrastructure. Plan exports of customer records, contracts and history in open formats, and confirm scope with your legal team. |
| Auditable access and change control | AICPA 2017 Trust Services Criteria, security common criteria CC1 to CC9 | Auditors expect evidence of who can change configuration and who can see customer data. Use named admin accounts, role-based access, enforced 2FA and logs of configuration and permission changes, and keep records of approvals. |
| Upgrade change control | EspoCRM security documentation; EspoCRM 10.0 release notes | UI upgrades are disabled by default as of version 10.0, so upgrades run through the CLI. Test each upgrade against Stripe, OIDC and custom formula scripts in a staging copy, and record the change as an approved change before production. |
Modules and settings that run recurring revenue in EspoCRM
Recurring revenue in EspoCRM depends on a handful of modules and settings that must agree with each other. The cards below cover the billing objects, the reporting and workflow engine, payment sync, status logic, customer access and staff sign-in, each with the decision to settle before build starts.
Subscription and billing plan entities
The Sales Pack is the official extension that adds sales documents and product catalog features to EspoCRM. Confirm which subscription and billing plan entities your installed version ships before designing around them, and do not assume the names used in other CRMs. Decide whether a subscription is a record linked to an account and opportunity, whether each billing period is a separate record, and which fields hold the plan, quantity, currency and renewal date. Ask the vendor which entities and fields exist in your version and test the data model against a sample customer before importing any accounts.
Advanced Pack reports and workflows
The Advanced Pack provides reports, Business Process Management and workflows, and it is included in all EspoCRM Cloud plans. For renewals, scheduled reports can list subscriptions ending within a chosen window, and workflows can assign follow-up tasks to account owners. Decide who receives each scheduled report, which filters define a renewal, and whether a workflow should create a task, change a status or send an email. Confirm whether your self-hosted edition includes the Advanced Pack and how its licensing applies before designing the renewal process.
Official Stripe extension
The official Stripe integration connects payments to CRM records so that invoices, charges and subscription events can be tied back to accounts. Decide which system is the source of truth for payment status, which Stripe objects sync into EspoCRM, and whether synced values are read-only in the CRM. Plan how failed payments trigger follow-up tasks, how refunds appear on the account, and who can view card-related data. Confirm the extension's current scope, supported Stripe objects and sync direction with the vendor before committing to a design.
Formula Script for status and date logic
Formula Script is EspoCRM's built-in scripting language, and it runs in before-save scripts configured in the Entity Manager, in API before-save scripts, and in workflows. For subscriptions, it can derive status from start, end and cancellation dates, and it can calculate the next renewal date when a plan changes. Decide which fields are calculated and which are entered by staff, and document every formula so that finance and support read the same status. Test edge cases such as mid-period upgrades, cancellations on the renewal date and backdated corrections before go-live.
Portal roles and customer access
Portal roles control what customers see when they log in to view their own subscriptions, invoices and support records. Decide which entities appear in the portal, which fields are visible, and whether customers can edit anything beyond their contact details. Confirm that each portal user is linked to the correct account so one customer cannot view another customer's billing data. Review the security guidance on session policy, password rules and IP restrictions for portal users, and keep staff and customer accounts separate.
OIDC or LDAP sign-in for staff
EspoCRM supports OpenID Connect sign-in since version 7.3, and its documentation also describes LDAP authentication for Active Directory and OpenLDAP. Decide which identity provider is the source of truth, whether first login creates users automatically, and how identity provider groups map to EspoCRM teams. EspoCRM's own two-factor authentication is not compatible with OIDC, so decide where second factors are enforced and keep a fallback login method for administrators. Plan backchannel logout and test offboarding so that a disabled employee loses access to billing records promptly.
Renewal workflows built from scheduled reports and BPM steps
A renewal workflow in EspoCRM usually starts with a scheduled report, not a workflow trigger on the subscription record itself. The report lists subscriptions whose renewal dates fall inside a window you choose, such as a set number of days ahead, and it runs on a schedule so the list refreshes without anyone opening it. A workflow or BPM process can then act on the results: it creates a renewal task for the account owner on each subscription, sets the due date from the renewal date, and notifies the owner. Before you build this, confirm in the installed Advanced Pack version which report-based triggers and scheduled report actions are available, since behavior differs between releases and the exact options are documented in the EspoCRM Advanced Pack page. Do not assume a trigger exists because a similar one does in another CRM.
Scheduled reports and workflows both depend on background jobs. EspoCRM's server configuration requires cron or a scheduled task to run them, so confirm that the job runs on your production host, that its output is logged, and that a failed run triggers someone's attention. A renewal list that silently stops updating is worse than none, because account owners will assume no renewals are due. Test the report filters against real subscription data rather than a handful of sample records. Check edge cases such as subscriptions with no renewal date, multi-year terms, subscriptions already renewed, and records whose owner has left the company and needs reassignment.
Where a renewal carries a discount, place an approval step between the renewal task and the quote or order. The workflow should route discounted renewals to a named approver, such as a sales manager or finance lead, and hold the renewal in a status that the account owner cannot advance on their own. Define the discount threshold that triggers approval in the formula logic or field values the process reads, and test both paths: a standard renewal that flows straight through and a discounted one that waits. Agree in writing which team owns the approval rules, because those rules change with pricing policy and need review whenever discount bands change.
Who gets which access: customers, internal teams and integrations
Customers who log in to see their subscriptions, invoices or support requests should never share a role with staff. In EspoCRM, portal users are governed by portal roles, which limit what they can read and edit, and they sit outside the internal team structure. Scope portal roles to the customer's own account records only, and test that a portal user cannot browse other accounts through list views, related records or direct links.
- Portal roles: Define a narrow portal role per product tier or customer type, and grant only the entities and fields the customer needs.
- Account isolation: Confirm that a customer sees only records linked to their own account, including renewals, invoices and tickets.
- Password policy: Apply the password policy to portal users as well as staff, and decide how customers recover access.
- Session length: Set a limit on authentication token lifetime that suits a customer-facing login.
- Second factor: Decide whether portal users need two-factor authentication, and confirm how that works with your sign-in method.
Check the portal role with a test customer account before go-live, and repeat the check after each change to layouts or permissions.
Sales and customer success staff need broad access to accounts, opportunities, subscriptions and renewals, but their access should follow the territories or portfolios they actually manage. EspoCRM uses roles to define what an user can do on each entity and teams to define which records they can see. Combine both so that a renewal manager sees the accounts in their portfolio without gaining access to finance-only fields or other regions.
- Roles: Create role sets for sales, customer success and renewals, with create, read, edit and delete levels set per entity.
- Teams: Assign users to teams that match portfolios, regions or segments, and check record visibility for each team.
- Admin for daily work: Do not let account managers work from administrator accounts. Keep administrator access separate and used only for configuration.
- IP restriction: Where staff work from known offices or a VPN, restrict access by IP address and confirm the allowlist with the network team.
- Session and password policy: Apply the same password rules and session limits used across the company.
Confirm the role and team matrix with the sales and success leads, and test visibility with a sample user from each team.
Finance staff handle billing plans, invoices, payment records and revenue fields, which makes them the group with the highest sensitivity in a subscription CRM. Access should separate the ability to view billing data from the ability to change plans, prices or payment status. Where the Stripe integration writes payment information, decide which fields finance can edit by hand and which must come only from the integration.
- Field-level control: Restrict billing, price and payment fields to finance roles, and keep them read-only for other groups.
- Separate duties: Avoid giving one person both the right to change a billing plan and the right to approve the related credit or refund.
- Team scope: Limit finance users to the billing records relevant to their function, if your structure allows it.
- Admin separation: Finance leads should not hold administrator rights for daily reconciliation work.
- Authentication: Require a strong second factor at the identity provider for finance logins, since EspoCRM's own two-factor authentication does not work with OIDC.
Review finance roles with the controller, and ask who can change payment status directly in the CRM.
Administrators can change the Entity Manager, roles, workflows and integration settings, so their accounts carry the highest risk. Use separate administrator accounts that are used only for configuration tasks, and keep daily work in standard accounts. The EspoCRM security documentation recommends avoiding admin accounts for daily work, disabling password recovery for admins, and enforcing two-factor authentication, which should be handled at the identity provider when you use OIDC.
- Separate accounts: Give each administrator a standard user account for daily work and a separate admin account for changes.
- Password recovery: Disable password recovery for admin accounts, as the security documentation recommends.
- IP restriction: Limit admin logins to a management network or VPN address range.
- Second factor: When OIDC is in use, enforce MFA at the identity provider, and confirm how the fallback login method is protected.
- Upgrades: Note that upgrading through the UI is disabled by default as of version 10.0, so administrators need a documented command-line upgrade path.
Confirm the administrator list, the fallback login owner and the recovery process before the platform goes live.
Integrations such as billing syncs, data warehouses or product usage feeds call the EspoCRM REST API through dedicated API users, not through a person's login. Each API user has its own role, so scope it to the entities and actions that the integration needs. The API documentation supports API key, HMAC and basic authentication. It describes HMAC as the most secure method and basic authentication as not recommended, so plan for HMAC wherever the integration allows it.
- HMAC authentication: Use HMAC for integrations where the client can sign requests, since the documentation describes it as the most secure option.
- Basic authentication: Avoid basic authentication, which the documentation does not recommend.
- Dedicated API roles: Give each integration its own API user and a role that grants only the required actions.
- Credential rotation: Store keys in a secrets manager, rotate them on a set schedule, and revoke keys when an integration is retired.
- Network scope: Restrict the API user to the IP addresses of the integration server.
Before go-live, ask the integration owner which authentication method the client supports, and list every API user with its role.
Rolling out subscription workflows in phases
This sequence moves a subscription business from agreed billing and lifecycle rules to a tested, supported EspoCRM instance, with each phase closed by a check that the next one depends on.
Map plans and lifecycle states
Finance and customer success agree the subscription plans, billing intervals, renewal terms and the lifecycle states an account moves through, such as trial, active, at risk, renewing and churned. Those states become the fields, statuses and pipeline stages you configure in the Entity Manager and layouts. The step is done when finance signs off the plan list and each state has a named owner and a defined entry rule.
Provision the server to documented requirements
Your infrastructure team builds the host against the EspoCRM server configuration: a supported PHP version, MySQL 8.0 or newer, MariaDB 10.6 or newer, or PostgreSQL 15, a supported web server, and a cron or scheduled task for background jobs. Confirm the current PHP range and the installation method for your environment before you start, since the docs are the reference. The step closes when a test instance answers over TLS and the background job scheduler runs without errors.
Import historical subscriptions with a dry run
Export existing subscription and account records to CSV and run a Create Only import in a test instance first. Set duplicate matching on the fields that identify an account, map the columns to your agreed plan and status fields, and check the results. Use the revert function to undo the dry run, then repeat with Create and Update for the live load. The step is done when record counts match the source and a sample of accounts shows correct plan, status and renewal dates.
Connect Stripe in a test setup
Connect Stripe in test mode first, using the official integration, and link test customers and subscriptions to CRM accounts. Confirm which events update CRM fields and which fields are read-only, and document who owns each webhook and key. Live keys are added only after finance has reconciled test payments against the expected plan records. The step is done when a test renewal and a test cancellation update the correct account in the CRM.
Build and test renewal workflows on copies of data
Build scheduled reports for upcoming renewals and at-risk accounts with the Advanced Pack, then attach workflows that assign owners, send reminders or move records between states. Formula scripts can calculate renewal dates and flags, so test each formula against known accounts. Run the workflows on a copy of production data, not the live instance, and compare outputs with what finance and customer success expect. The step is done when the scheduled reports match a manual check for a defined sample.
Enable SSO and the access policy
Configure OpenID Connect sign-in with your identity provider, decide whether users are created on first login, and map identity groups to EspoCRM teams. Set the password policy, require two-factor authentication where OIDC is not in use, keep admins off daily accounts, limit token lifetime, and restrict admin access by IP address. Confirm the fallback login method is tested before enforcing SSO. The step is done when a test user lands in the correct team with only the permissions the role grants.
Pilot the customer portal with a small group
Give a small set of customers portal access with a defined portal role and check that they see only their own subscriptions, invoices and tickets. Ask the pilot group to report unclear fields, missing records and access problems, and fix permissions before widening access. The step is done when pilot users confirm the data they see is correct and no record outside their account is visible.
Cut over and agree the upgrade plan
Freeze the import, run a final reconciliation against billing records, switch Stripe to live keys and open the instance to the full team. Before the first major version change, agree an upgrade plan that covers extensions, custom formulas, PHP compatibility and the CLI upgrade process, since upgrading through the UI is disabled by default as of version 10.0. The step is done when reconciliation is signed off, backups are confirmed, and a named owner holds the upgrade plan.
Compliance evidence a SaaS business will be asked for
SaaS buyers and assessors usually ask for evidence about how customer data is handled, not for a tool. The cards below cover the frameworks most often raised when a CRM holds subscription, billing and customer contact data, and what each one expects from the EspoCRM deployment.
SOC 2 trust services criteria
A SOC 2 examination is scoped against five trust services categories: security, availability, processing integrity, confidentiality and privacy. The security common criteria, CC1 to CC9, apply to every SOC 2 examination whatever categories are in scope. For EspoCRM, check which categories your report covers, and which systems, including the CRM, its database, backups and API users, sit inside the system description.
Type 1 design versus Type 2 operation
A Type 1 report describes the system and whether controls are suitably designed as of a single date. A Type 2 report adds an opinion on whether those controls operated effectively over a period. Buyers usually ask for Type 2. Before the observation window opens, you need access reviews, change records and backup restore tests that run on a schedule, because an auditor will sample them from the period.
ISO/IEC 27001:2022 Annex A themes
Annex A of ISO/IEC 27001:2022 groups its controls into organizational, people, physical and technological themes. Many EspoCRM controls map to the technological theme, such as authentication, access rights and logging. Certification is granted by an accredited certification body, not by ISO, and the certificate runs on a three-year cycle with audits in between. Confirm with your certification body which Annex A controls they will test against your CRM.
GDPR Article 28(3) processor terms
When a SaaS business uses a CRM to hold customer contact, billing and support data for others, the relationship with the hosting or implementation provider must be governed by a processor contract. Article 28(3) requires that the processor acts only on documented instructions, including for transfers, and applies the security measures of Article 32. Keep a record of who can export or delete CRM data, and make sure the contract reflects that.
EU Data Act switching duties
If your business offers data processing services to EU customers, the Data Act requires that customers can switch to another provider or to on-premises infrastructure. The regulation applies from 12 September 2025 and sets a maximum two-month notice period and a 30-day transitional period. Self-hosted EspoCRM keeps export paths under your control, so check that data, customizations and attachments can be extracted in usable form.
NIS2 scope check
NIS2 applies by sector. Its Annex I covers cloud computing, data center and content delivery providers, and managed service providers, all treated as high criticality. A SaaS business outside these sectors may not be in scope, but a customer in a covered sector may still ask for controls. Confirm your classification with counsel before you map CRM controls to NIS2 obligations.
What drives the cost of an EspoCRM build for subscription revenue
This table separates the cost components of a subscription-focused EspoCRM build by who is paid, whether the cost is one-time or recurring, and what moves it. Use it to build a quote request that compares like with like. The main takeaway is that the software line is often the smallest part of the total, and the largest swings come from integration, migration and identity scope.
| Cost component | Who is paid | One-time or recurring | What moves the cost up or down |
|---|---|---|---|
| Software licensing | EspoCRM (cloud subscription) or no licence fee for self-hosting | Recurring for EspoCRM Cloud, per user per month on plans with minimum user counts; none for the self-hosted open-source edition | Cloud pricing depends on plan tier and seat count; the Advanced Pack is included in all cloud plans per the EspoCRM pricing page |
| Infrastructure and hosting | Your cloud provider or data center, and any managed database service | Recurring | Server count, database engine, backup storage, mail relay and high availability design; confirm sizing with your platform team |
| Extension licensing | Vendor of each extension you add, such as the Sales Pack or Stripe integration | Confirm whether one-time or recurring with each vendor before scoping | Number of extensions, whether they are included in your plan, and whether you need a paid tier for billing features |
| Implementation scope | DeployOpen or your internal team, for design, configuration and testing | One-time | Number of subscription plans, billing models, renewal rules and custom entities; a fixed scope agreed in writing sets the boundary |
| Stripe integration | Implementation partner, for webhook handling, mapping and reconciliation | One-time build, with recurring monitoring | Number of Stripe event types mapped, handling of failed payments and refunds, and reconciliation requirements |
| Data migration | Implementation partner or internal team, for mapping and cleansing | One-time | Volume and quality of existing subscription and contact records, number of source systems, and duplicate rules |
| Portal and identity work | Implementation partner, plus your identity provider team | One-time build, with recurring identity operations | Number of portal roles, whether single sign-on uses OIDC or LDAP, and group-to-team mapping complexity |
| Ongoing support and upgrades | DeployOpen or your internal team, under a retainer or internal allocation | Recurring | Frequency of EspoCRM releases, extension updates, PHP version changes and the amount of custom code to retest |
What does an EspoCRM for subscription and SaaS businesses build cost and need from us?
What does an EspoCRM subscription build cost, and what drives it?
The cost is set by the written scope, not by a list price, and DeployOpen does not publish one. The main drivers are the number of subscription products and billing plans, how many custom entities and layouts are needed, how many formula scripts and renewal workflows are built, the Stripe and identity provider integrations, and the volume and quality of historical data to migrate. Each item adds design, build, testing and handover effort. Recurring costs sit outside the build: EspoCRM's own licensing differs by edition, and the open-source edition can be self-hosted for free. Ask any partner for a quote that separates one-time build work from ongoing support, hosting and upgrades, and that lists each integration as its own line.
How long does it take to get a working renewal process?
Duration depends on how many renewal stages exist, how cleanly the billing plans map to CRM records, and how quickly your finance team confirms the rules. A renewal process built on scheduled reports and workflows usually moves faster when the subscription data is already clean and the plan catalogue is settled before build starts. Delays usually come from unresolved pricing rules, late decisions on who owns each renewal stage, and waiting on access to the identity provider or payment account. Ask for a timeline in the written scope with milestones for data mapping, a test cycle using real renewal dates, and sign-off from finance before go-live.
What does our team need to provide before implementation starts?
Your team needs to supply the inputs that the design depends on:
- A plan catalogue listing each product, billing plan, price point, billing interval and discount rule.
- Historical subscription exports covering active, paused and cancelled accounts, with contract start and end dates.
- Finance sign-off on how renewals, proration, credits and churn are recorded.
- Administrative access to your identity provider so single sign-on can be configured and tested.
- Named business owners who can decide sales, renewal and support processes quickly.
Missing or inconsistent inputs are the most common reason an engagement slows down, so confirm these items in writing before the build is priced.
Can an in-house team build this without outside help?
An in-house team can build it if it already has someone comfortable with EspoCRM's Entity Manager, layouts, Formula Script and the Advanced Pack's workflows, plus engineers who can run the server, cron jobs and the identity integration. Teams that lack one of these areas often spend more time learning than building. Outside help is most useful for the design decisions that are hard to reverse, such as how subscriptions relate to accounts and opportunities, and for testing renewals against historical data. A useful test is whether you can name who will maintain the custom logic after go-live and who will handle upgrades.
Should we run EspoCRM in the cloud or self-host it?
EspoCRM Cloud is priced per user per month on published plans, and the Advanced Pack is included in every cloud plan. Self-hosting uses the open-source edition, which can be downloaded and run for free, but you then own the server, PHP and database versions, cron jobs, backups, TLS and upgrades. Choose cloud when you want the vendor to run the platform and you accept its hosting terms. Choose self-hosting when you need control over where customer and billing data lives, custom server configuration, or your own identity and network controls. The EspoCRM server requirements list PHP 8.3 to 8.5 and MySQL 8.0 or newer, MariaDB 10.6 or newer or PostgreSQL 15, so confirm your team can operate that stack.
How is Stripe connected to EspoCRM for billing data?
Stripe is connected through the official Stripe integration extension, which the EspoCRM integrations are built around. The build defines which Stripe objects map to which CRM records, how payment events update subscription status, and which fields are read-only so that billing data is not edited by hand in the CRM. Plan the handling of failed payments, refunds and plan changes before build, because these drive status updates and renewal reminders. Confirm the extension version and its compatibility with your EspoCRM version, and test with Stripe test-mode data before connecting live accounts. Your payment card data should stay with Stripe, and the CRM should hold only the references it needs.
How are EspoCRM upgrades planned after go-live?
Upgrades are planned around the custom entities, formulas, workflows, extensions, PHP version and the CLI upgrade process. EspoCRM 10.0.0 was released on July 2, 2026, and 10.0.10 on October 14, 2026, according to the release history on GitHub, so plan a test copy of the instance and a rollback point before each change. The security documentation notes that upgrading through the UI is disabled by default as of version 10.0, so the upgrade runs through the command line. Ask for an upgrade plan that lists each custom component, its test cases, and who approves the production change. Ongoing support and upgrades can be agreed as a retainer.
What does compliance support include for a subscription business?
Compliance support prepares the system, configuration and evidence that an independent auditor will review. It can include documenting access roles, enforcing password and two-factor policies, configuring identity federation, setting up backups and restore tests, and recording how customer personal data is handled. DeployOpen does not issue audit reports, attestations or certifications. Independent auditors and certification bodies do that work. If you are preparing for a SOC 2 examination, ask which Trust Services Criteria are in scope, since the security common criteria apply to every SOC 2 report, and confirm with your auditor which controls they will test and over what period.
How DeployOpen scopes and supports subscription EspoCRM builds
DeployOpen plans, implements, customizes, integrates, hardens, documents and supports EspoCRM inside your own infrastructure, including the cloud accounts, data centers or air-gapped networks you control. For subscription and SaaS businesses, that means the plan, billing model and renewal logic are agreed in writing before any configuration starts.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- We map your plans, add-ons, billing cycles, renewal dates and cancellation rules to specific EspoCRM entities and fields.
- We confirm which Sales Pack and Advanced Pack features your team needs, and which payment and portal flows are in scope.
How we build
- We configure custom entities, layouts, formula logic and scheduled reports for subscriptions, renewals and churn tracking.
- We build and test Stripe and customer portal integrations against non-production data before any live payment flow is enabled.
- We test renewal workflows with sample accounts, checking dates, notifications, permissions and report output at each step.
How we hand over
- You receive documentation of the data model, formulas, workflows, integrations and the access roles behind each one.
- We provide runbooks for cron-driven background jobs, backups and restores, and the upgrade steps for future EspoCRM versions.
- Handover includes a review of password policy, two-factor authentication, admin account use and API user permissions.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, scoped in writing like the original build.
- Retainers can cover extension updates, PHP and database version changes, and checks after each new EspoCRM release.
- Ask any provider to confirm how they handle payment data scope, access logs and incident response before work begins.
