When EspoCRM case management and customer portal setup makes sense
EspoCRM case management and customer portal setup makes sense when your team handles customer requests arriving by email, web forms, phone and API, and needs one record for each case with a clear owner and history. Instead of scattered inboxes and spreadsheets, cases sit next to the accounts and contacts they belong to. The EspoCRM case management docs describe four ways a case can be created: manually by a CRM or portal user, through the API (for example from a web form), automatically from emails sent to a specific mailbox, or by a workflow rule. That covers most intake paths a support or service team uses, and the email route is the one most teams check first, since it depends on group mailboxes and how replies are threaded back to the case.
The second driver is customers who must see only their own items. The portal docs say administrators can create several portals, each with its own settings, dashboard, users and access control, and that portal roles add the access levels own, account and contact. Those levels decide whether a customer sees only cases they opened, every case under their account, or cases under their contact record. Internal stream posts are hidden from the portal, which keeps staff notes out of view, but this only works if your team uses the internal flag consistently. Custom entities can take part in account and contact access only when they are linked to Account or Contact through the ACL Account Link and ACL Contact Link parameters, so confirm that link design before you build the portal.
EspoCRM is not a replacement for a dedicated ITSM platform when you need formal change management, asset-linked incident workflows, complex service catalogs or deep SLA engines. Check those requirements against the module before committing, and confirm with the vendor which SLA and escalation features are available in your version. If your team mainly needs customer-facing support tied to sales and account data, the case module is a strong fit. If you also need internal IT service management, plan that as a separate tool or decide explicitly how the two systems will share records. Review the case management and portal documentation with your team before you define the access model.
What EspoCRM case management includes
Case management in EspoCRM covers how cases enter the system, what customers can see, and who can see what in each portal. The cards below cover the intake paths, the internal versus customer-facing split, portal boundaries, and the Advanced Pack dependency that shapes the design. Each one is a decision to settle before configuration starts.
Multiple intake paths for cases
Cases can be created manually by CRM or portal users, through the API (for example from a web form), automatically from emails sent to a specific mailbox, or by a workflow rule. Each path brings different data quality and different ownership defaults. Decide which paths you need at launch, map the fields each one must populate, and test each path with real sample messages before go-live. Confirm how the API user for a web form is permissioned.
Email-to-case from group mailboxes
A group mailbox can route inbound email into cases, so customers write to a support address instead of a named agent. The design questions are which mailbox feeds which case type, how replies are threaded back to the existing case, and who receives unassigned items. Confirm mailbox connection settings and duplicate handling in your own environment, since mail provider behavior varies.
Internal stream posts hidden from customers
Stream posts marked as internal stay hidden from the customer portal, which lets agents discuss workarounds, escalation notes and billing questions on the same case. The risk is a post written as public by mistake, so agent training and a review step matter. Decide which roles can post internally and whether internal discussion should also be restricted at the record level.
Separate portals with their own settings
Administrators can create multiple portals, and each has its own settings, dashboard, users and access control. This fits organizations that serve distinct customer groups, such as enterprise accounts and a public community. Plan the portal list, the users and dashboard per portal, and the domain each portal will use before building anything. Confirm the hosting and domain steps with your deployment design.
Portal roles with own, account and contact access
Portal roles add the own, account and contact access levels, which determine whether a portal user sees only their own records, all records under their account, or records linked to their contact. Choose the level per entity, not per portal alone. Test with a user from each account to confirm nobody sees another customer's cases. Use the access levels as a starting model, then review them against your data sharing rules.
Custom entities need account or contact links
As of version 9.0, custom entity types need relationships to Account or Contact, selected in the ACL Account Link and ACL Contact Link parameters, before the account and contact access levels apply. Entities without these links fall back to narrower access. Confirm the link design before creating custom case-related entities such as service contracts or product units. Workflows and reports used for service work depend on the Advanced Pack, which is included in EspoCRM Cloud plans, so confirm the self-hosted licensing path.
How cases enter the service desk
Portal submissions are the path where customers create cases themselves. The portal is configured under administration as a portal with its own settings, dashboard, users and access control, and each portal user is linked to an account or contact and given a portal role. The portal role decides what a customer sees and edits, using the own, account and contact access levels, so the role must be scoped deliberately before users are invited.
- Portal and domain: Create the portal, choose its dashboard and decide whether it runs on its own domain, which is part of the deployment design you confirm before testing.
- Portal roles: Set the Case access level to own, account or contact for each customer type, and confirm that a customer cannot list cases belonging to another account.
- Account linkage: Link every portal user to the correct account or contact record, because the account and contact levels depend on that link.
- Internal posts: Mark stream posts as internal where staff notes must stay hidden from customers, then verify they do not appear in the portal.
- Invitation flow: Send a test invitation to a non-production address and confirm the first login works.
Before go-live, log in as a test customer from each account type and confirm they see only their own cases, and that an internal note posted by a staff member is not visible.
Email-to-case turns messages sent to a specific address into cases. The reader needs a dedicated group mailbox, typically a shared support address, that EspoCRM can poll, plus a clear rule for how replies from customers attach to existing cases instead of opening new ones. Mailbox access is a platform decision: confirm with your mail provider which protocol and authentication method it supports for the inbound connection and whether a service account is permitted.
- Mailbox identity: Create a dedicated group mailbox and a service identity that can read it, with credentials stored outside the application configuration in line with your secrets policy.
- Group email account: Configure the group inbound account, assign it to a team, and set the default case owner or assignment rule.
- Filters and folders: Decide which folder or label EspoCRM reads and keep automated replies and newsletters out of the case queue.
- Reply threading: Confirm that replies from customers attach to the existing case, using the case reference in the subject, and that new messages create a new case.
- Background jobs: Confirm that the scheduled job that fetches email is running, since intake stops silently when it does not.
Before go-live, send a message from an external address, a reply to it and an automated message, then check that the first creates one case, the reply attaches to it and the automated message is ignored.
Cases can also be created through the REST API, which a web form or another system can call. The integration should use a dedicated API user with a role that allows only case creation, not an administrator account. The security documentation favors HMAC over basic authentication, and basic authentication is described as not recommended, so the authentication method should be chosen before the form is built.
- API user: Create an API user with a role limited to creating cases and reading only the fields the form needs.
- Authentication: Choose HMAC for server-to-server calls and confirm that the calling system stores the secret in its own secrets store.
- Field mapping: Map form fields to case fields, and map the requester to an existing contact or account so the case is linked correctly.
- Validation and spam: Validate input on the form side and decide how the integration handles duplicate submissions.
- Network access: Restrict which addresses can reach the API endpoint, using the IP restriction options described in the security documentation.
Before go-live, submit a test case from the form and confirm the case appears with the correct account, contact and priority, and that the API user cannot perform actions outside its role.
Workflow rules create cases from other records, for example when an order fails, a contract renewal is missed or a monitoring integration posts a status change. This path depends on the Advanced Pack, which provides Business Process Management and workflows, so confirm the extension is licensed or installed in your environment. The rule should be explicit about the trigger, the condition and the case fields it sets, so that every automated case has an owner and a source.
- Trigger and condition: Define the record type, the trigger event and the condition that fires the rule, and document it for the operations team.
- Case template: Set the case type, priority, owning team and account or contact link inside the action, so no case is created without ownership.
- Duplicate control: Add a check that prevents the same triggering record from opening several cases.
- Formula logic: Use Formula Script where a field value must be calculated or validated before the case is created.
- Permissions: Confirm the workflow runs under a user who can create cases in the target team.
Before go-live, trigger the rule with a test record, confirm exactly one case is created with the expected owner, and confirm that changing the source record again does not create a second case.
Portal access and case design decisions
This table compares the main design choices for EspoCRM case management and portals, including portal count, access levels, custom entity links, mailbox routing and knowledge base visibility. Read each row to see when an option fits and what becomes harder to change once records and portal users exist.
| Decision | When it fits | Trade-off | Cost of changing later |
|---|---|---|---|
| One portal or several | One customer base with one set of branding and rules fits a single portal; separate customer groups with different dashboards, users or access control fit separate portals | Each portal has its own settings, dashboard, users and access control, so every extra portal is another configuration to maintain | Moving customers between portals means reassigning portal users and re-checking dashboards and access control |
| Own access level | Customers should see only the cases or records they created or own | Narrowest visibility, but a customer cannot see colleagues' cases on the same account | Widening to account or contact access later changes what every existing portal user can see, so test it with sample users first |
| Account access level | Customers at the same organization should see each other's cases and records | Requires cases and related records to be linked to the Account, and a mistake in account assignment exposes data across the organization | Re-linking historical cases to accounts is a data cleanup task that grows with case volume |
| Contact access level | Individual contacts should see only their own requests within a shared account | Depends on accurate contact-to-case links, and contacts who change employers need their links reviewed | Changing the contact model after go-live affects portal visibility for every affected user |
| Custom entities linked to Account or Contact | Use when a custom entity, such as a service asset or contract, must follow account or contact access | Only applies with the ACL Account Link and ACL Contact Link parameters, available as of version 9.0; without them, account and contact levels do not extend to the entity | Adding the link after records exist requires backfilling relationships for every existing record |
| Group mailbox ownership | A shared support address should feed a team queue, with cases routed to the owning team | Shared mailboxes simplify intake but need clear rules for who replies and who is assigned | Switching from one mailbox to several splits history and may require re-pointing inbound addresses and rules |
| Team routing for cases | Routing by team fits support tiers, regions or product lines | More teams give finer control but more assignment rules to test and keep current | Restructuring teams later changes case visibility and workflow assignments, so plan the team model before go-live |
| Knowledge base shared internally | Staff-only articles fit runbooks, escalation steps and internal policy | Internal content stays out of the portal, but agents must still find and maintain it | Moving articles to customer visibility later requires an editorial review for accidental disclosure |
| Knowledge base exposed to customers | Public how-to and troubleshooting content reduces repeat cases | Every article becomes customer-facing, so reviews and ownership must be assigned before publication | Pulling published articles back after customers have bookmarked them creates support friction |
Implementation sequence for the service desk
This sequence moves a service desk from a bare EspoCRM instance to a tested case model, portal and intake channels, with each step producing a sign-off artifact the next step depends on. The order matters because portal visibility and mailbox routing both depend on the data model and access matrix being settled first.
Confirm EspoCRM version and hosting
Fix the EspoCRM version, the hosting model and the server stack before any configuration begins. Confirm the PHP, database and web server combination against the server configuration docs, confirm that cron or a scheduled task runs background jobs, and confirm whether the Advanced Pack is needed for the workflow rules you plan. Your team or DeployOpen records the decision in a short environment record that lists the version, hosts, database, mail server and identity provider. The step is done when the staging and production environments are built from that same record.
Define the case model and statuses
Agree the case fields, categories, priorities, statuses and the stages a case moves through, including who may set each status. Map each case type to the team that owns it and decide which fields customers see and which stay internal. Write the result as a case model document that names every field, status and transition. The step is done when service leads have signed off the model and the status list has no ambiguous states.
Build account and contact data
Create or confirm the Account and Contact records, their relationships and the customer data quality rules that portal access will depend on. Decide how a contact belongs to an account, how shared customers are handled, and whether any custom entity must link to Account or Contact so the account and contact access levels work for it. Load a small set of test accounts and contacts. The step is done when every portal user can be traced to exactly one account or contact path in the test data.
Configure portal roles and access matrix
Create the portal, its dashboard and its portal roles, then set the own, account and contact access levels for each entity and action. Approve an access matrix that lists each role against each entity, the access level granted and the internal stream posts or fields hidden from customers. Apply the security baseline for portal and API users, including password policy and 2FA where the platform supports it. The step is done when the approved access matrix matches the configured roles one for one.
Set up group mailboxes and email-to-case
Create the group mailboxes, connect each one to the correct team and case type, and define the routing map that sends each inbound address to its queue. Test inbound and outbound mail for every mailbox, including replies that must attach to an existing case. Confirm that background jobs process mail on schedule. The step is done when a tested mailbox routing map shows every address, its target team and a passing test message for each route.
Build workflow rules and API intake
Build the workflow rules that assign, escalate or notify on cases, and configure the API intake used by web forms or other systems. Create a dedicated API user with the narrowest role that can create cases, and choose the authentication method documented for API users. Record each rule's trigger, condition and expected outcome in a rule register. The step is done when every rule and API route has a written test case with a pass result.
Test portal visibility with real test users
Sign in as test customers, test agents and a test API user, one for each role in the access matrix, and attempt every action the matrix allows and forbids. Confirm that internal stream posts stay hidden from portal users, that customers see only their own account or contact records, and that attachments and related records follow the same rules. Log every failed check and fix it before retesting. The step is done when a signed test log shows zero open access failures against the matrix.
Pilot, then hand over
Run a controlled pilot with a limited group of customers and agents, watch mail routing, assignment and portal sign-in, and collect defects in one list. Fix the defects, rerun the affected tests from the earlier steps and then agree the handover. Handover includes the access matrix, routing map, rule register, runbook for mailbox and job troubleshooting, and the named owner for each case type. The step is done when the pilot exit criteria are met and the operations team accepts the runbook.
How portal roles keep customers inside their own account
Portal roles decide what a customer can see, and the three access levels are the core of that decision. The level own limits a portal user to records they created or are assigned to, account extends visibility to records linked to the customer's account, and contact limits it to records linked to the individual contact. Choose the level per entity in the portal role, not once for the whole portal, because a customer may need account-wide visibility of cases while only seeing their own tasks. Stream posts marked internal are hidden from the customer portal, so staff notes can sit on the same case without being exposed. Confirm that behavior in a test portal before you rely on it for sensitive escalation notes, since internal notes are only protected if staff use the internal flag consistently.
Custom entities do not inherit account or contact access on their own. The portal documentation says a custom entity type needs a relationship to Account or Contact, selected in the ACL Account Link and ACL Contact Link parameters, before the account and contact levels apply (as of version 9.0). If a team builds a custom entity for warranty claims or installations and skips these links, portal users may see nothing beyond own records, or the entity may be exposed in ways nobody planned. Map every custom entity that customers should reach to its account or contact link during design, and record that mapping in the access specification so the build team and the reviewer check the same thing.
Test the matrix with at least two customer accounts, each with more than one user, before go-live. Create users in Account A and Account B, give them the same portal role, and confirm that each sees only its own cases, contacts and custom records, including direct URLs and list filters. Keep API users and administrator accounts out of the portal entirely: API users should authenticate with dedicated accounts and roles, and administrators should not double as portal logins. The EspoCRM security guidance also recommends avoiding admin accounts for daily work and requiring two-factor authentication where it fits your setup, so verify those settings alongside the portal matrix. Document each test result, because the matrix becomes evidence when an auditor or your own security team asks how customer isolation was verified.
What drives the effort and how to keep it down
This table lists the main factors that change the effort of a case management and portal setup, the work each one adds, and how to keep it contained. Read it as a scoping checklist: the drivers that multiply each other, such as portals combined with SSO and custom entities, deserve the closest attention in discovery. Starting with one portal and one mailbox is usually the fastest way to reduce scope before adding channels.
| Driver | Why it changes effort | How to keep it down |
|---|---|---|
| Number of intake channels | Each channel (portal form, API, email, workflow rule) needs its own intake design, validation and testing. | Start with the one or two channels that carry most volume and add others after go-live. |
| Number of mailboxes and teams | Each group mailbox needs its own connection, team assignment, routing rules and monitoring. | Begin with one group mailbox and one team, then split by queue once volumes are known. |
| Complexity of the case model | Custom statuses, priorities, types and required fields multiply layouts, validation and reporting. | Keep the default case fields and add only the ones your service levels depend on. |
| Custom entities linked to Account or Contact | Portal access levels for account and contact only work when the custom entity has the right link parameters, so each one needs design and access testing. | Limit custom entities to those customers must see, and test each one under a portal role before rollout. |
| Number of portals | Each portal has its own settings, dashboard, users and access control, so each one repeats configuration and testing. | Launch a single portal first and reuse its settings as the template for any later portal. |
| Quality of existing account and contact data | Duplicates, missing account links and inconsistent emails break email-to-case matching and portal visibility. | Cleanse and deduplicate before import, and confirm which records each customer user should see. |
| SSO or 2FA alignment | OIDC or LDAP sign-in for staff and portal users needs identity provider configuration and fallback login planning, and EspoCRM's own 2FA is not compatible with OIDC. | Decide the identity model in discovery, and confirm which users are covered by the identity provider before building portal logins. |
How case management connects to the rest of the platform
A case desk in EspoCRM depends on four connections: who signs in, which systems create or update cases, how mail reaches the right queue, and which automation routes work. Each one changes the portal and support design, so decide them together before the build starts.
OpenID Connect sign-in and group mapping
EspoCRM supports OpenID Connect sign-in, with optional user creation on first login and mapping of identity provider groups to EspoCRM teams. Use this to place staff into the right support teams without manual administration. Decide early how portal customers authenticate, because EspoCRM's own two-factor authentication is not compatible with OIDC. Confirm where second-factor enforcement will live, whether in your identity provider or elsewhere, and test the fallback login method before go-live.
API users with HMAC authentication
Web forms, monitoring tools and other systems that create cases should use dedicated API users with role-based permissions, not personal accounts. The EspoCRM API docs describe HMAC as the most secure method and basic authentication as not recommended. Scope each API user's role to case creation and the entities it needs, and confirm the key rotation process with the team that owns the calling system.
Formula Script in workflows
Formula Script is EspoCRM's built-in scripting language. It runs in before-save scripts configured in the Entity Manager, in API before-save scripts, and in workflows and BPM. Use it for priority rules, default owners and status changes that must hold regardless of how a case was created. Keep logic in one layer where possible, so a case created by email and a case created through the API follow the same rules.
Group mailboxes and email-to-case
Email-to-case creates a case automatically from mail sent to a specific mailbox, so a shared address such as support can feed the queue. Plan the mailbox set up around who monitors it, how replies are threaded to existing cases, and how inbound mail from customers is matched to accounts and contacts. Test with real message patterns, including auto-replies and forwarded threads, and confirm that outbound mail uses the sender identity your customers expect.
Advanced Pack workflows that route cases
The Advanced Pack adds Workflows and Business Process Management, and it is included in all EspoCRM Cloud plans. Use workflow rules to assign cases to teams, escalate aging items and trigger notifications when a status changes. Map each routing rule to a named owner and document the fallback when no team member is available. For self-hosted deployments, confirm the extension licensing with EspoCRM before you plan the build.
Portal identity decided early
Portal customers and internal staff often need different identity paths, and the choice affects accounts, roles and support load. Decide whether customers sign in through a local portal login, an identity provider or both, and whether self-registration is allowed. Record how a customer's contact is linked to an account before a case is created, because portal visibility depends on that link.
Questions buyers ask about EspoCRM case management and portal setup
What does an EspoCRM case management and portal setup cost?
The cost depends on the written scope, not on a list price. The main components are the discovery and design of case types, portal roles and mailboxes, the build of custom entities, layouts and workflows, the portal and identity configuration, testing, and handover. The license is separate: the open-source edition can be downloaded and self-hosted for free, according to the EspoCRM pricing page. Workflow and business process features need the Advanced Pack, which is included in all EspoCRM Cloud plans. For a quote, ask for the case types and channels in scope, which portals are needed, how many mailboxes and identity integrations are involved, what testing is included, and what runs after go-live. DeployOpen does not publish prices, and the quote follows from the agreed scope.
How long does it take to set up EspoCRM cases and a customer portal?
Duration is set by the number of case types, the number of portals, the integrations and the approvals needed before go-live. Email-to-case adds time because mailbox access, forwarding rules and test messages must be coordinated with the people who own the mail domain. Portal access adds time when account and contact relationships must be modeled for custom entities, and when single sign-on is part of the design. Ask for a timeline that lists each phase, the client decisions it depends on and the acceptance tests. The written scope should state the target dates before work starts.
What does our team need to provide for the project?
Plan to provide decision owners for case categories, priorities, service levels and who sees what in the portal. You will also need administrative access to the mail domain or group mailboxes used for email-to-case, the identity provider if customers or staff sign in through single sign-on, and a sample of real customer data for the import and testing phase. A named person should approve the portal roles, because account and contact visibility decides what customers can read. Your team should also confirm the hosting environment, backup ownership and who will operate the system after handover.
Can our team set up EspoCRM case management alone using the documentation?
A capable administrator can configure basic cases from the official documentation, including case creation from the user interface, manual cases and simple portal settings. The harder parts are the ones where mistakes affect customer data: portal roles with account and contact access levels, custom entities linked to Account or Contact through the ACL Account Link and ACL Contact Link parameters, email-to-case with group mailboxes, and the security baseline. Those need testing with non-admin accounts and a review of permissions. Decide early which parts your team can own, and which parts you want reviewed or built by a partner under a written scope.
Which parts of case management need the Advanced Pack?
The Advanced Pack is an official add-on that provides reports, Business Process Management and workflows, according to the EspoCRM Advanced Pack page. It is included in all EspoCRM Cloud plans. If your design relies on workflow rules that create cases automatically, the Advanced Pack is part of the design. Some case features in the case management documentation can be configured without it, so confirm the exact feature list against the current documentation for your version. For a self-hosted deployment, confirm whether you will license the Advanced Pack, since the open-source edition is the base for the installation.
What is needed to upgrade an EspoCRM case management setup later?
An upgrade needs a test copy of the production instance, a backup taken before the change, and a review of custom entities, layouts, workflows, portal settings and email configuration. EspoCRM 10.0.0 was released on July 2, 2026, and 9.0.0 on January 20, 2025, according to the EspoCRM releases page, so check the release notes for each version you cross. The security documentation notes that upgrading through the user interface is disabled by default as of version 10.0, so plan for the command-line upgrade process. Confirm the PHP and database versions required by the target release before scheduling the work.
How do we keep customer portal users from seeing internal case notes?
Stream posts marked as internal are hidden from the customer portal, according to the EspoCRM case management documentation. Confirm that every staff member who writes to a case uses the internal option when needed, and test the portal with a customer account before go-live. Portal roles should be scoped to the customer's account or contact, and each portal should have its own users and access control. Include this check in the acceptance tests, and repeat it after any change to roles, layouts or relationships.
What to put in the written scope before a partner starts
Put the scope in writing before any build starts, because DeployOpen works from a fixed, written scope with agreed deliverables and timelines. For a case management and portal project, that scope should name every intake channel as a separate line item: portal forms, the web form or API calls that create cases, each group mailbox that feeds email-to-case, and any workflow rules that create cases automatically. Each channel needs an owner, a expected volume, and a decision on what a new case must contain before it is saved. Also list each customer portal by name, since the portal docs allow several portals with their own settings, dashboard, users and access control. For every portal, state which portal roles apply (own, account or contact) and which custom entity types need an Account Link or Contact Link so those access levels work.
Ask any partner to confirm the platform facts that change the work. Confirm the EspoCRM version you will run, since the current major line and its upgrade notes differ from older releases, and confirm the PHP and database versions against the server configuration docs before anything is provisioned. Confirm hosting: where the instance runs, who holds administrator access to the server, and how the mail, cron and backup jobs are handled. Confirm extension licensing in writing. Case management relies on features in the Advanced Pack, which is included in EspoCRM Cloud plans but must be licensed separately for a self-hosted instance, so ask the partner to state which extensions the scope depends on and who buys them. Also ask whether the quote includes ongoing extension and upgrade work.
Close the scope with handover items and the controls you expect to see at go-live. Name the knowledge base articles that must be migrated or written, the internal stream post rules that keep internal notes out of the portal, the API users and their authentication method, and the single sign-on or two-factor requirements for customers and staff. Ask for written acceptance tests for each intake channel and portal, a list of admin accounts and their purpose, and the documentation and training your team will receive. Anything not written into the scope is a change request, so list recurring costs such as hosting, mail services and extension renewals separately from one-time build work, and ask the partner to show both in the quote.
How DeployOpen scopes and delivers EspoCRM case management
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For EspoCRM case management and customer portal setup, we start from a written scope covering case intake channels, portal roles and the records your support teams work in, then build and test it in your environment before handover.
How we scope
- Agree in writing which case intake channels are in scope: portal, email, API, web form or workflow rules.
- Map each portal to its customers, accounts, contacts and the access levels each portal role should receive.
- Confirm mailboxes, group addresses, dashboards and internal-only stream post practices before any build begins.
How we build
- Configure case entities, layouts and assignment logic in EspoCRM, including Account or Contact links for custom entities.
- Set up email-to-case with your group mailboxes and test routing, threading and auto-responses with sample messages.
- Test portal access with a set of representative customer and staff accounts to confirm each role sees only its own records.
How we hand over
- Deliver written documentation of portal roles, intake channels, mailbox settings and internal stream post conventions.
- Walk your administrators through permission design, so changes to access follow the documented model.
- Provide a list of open items and the decisions your team still needs to make after handover.
How we support
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
- Ongoing support, upgrades and periodic access reviews are available as a retainer.
- Quotes follow from the written scope, so ask for the components, assumptions and recurring costs to be itemized.
