Skip to content
← Back to blog
custom-softwareArticle

A custom customer portal instead of a CRM add-on

A custom customer portal is worth considering when a CRM add-on cannot support your request workflow or access rules. Check its configuration options and available plans first. If gaps remain, you can build a focused portal for status updates, documents, and approvals while keeping the CRM as the main source of customer data.

Author

Syntalith

Published Updated 6 min read

A customer asks for the current version of a document, sends a correction, and then their manager approves an older attachment. The account manager sorts through the correspondence and records the agreed changes in the customer relationship management system, or CRM. In this illustrative situation, giving the customer a list of tickets may leave much of the work unresolved. The purchase needs to cover the full path from a customer's request to confirmation that it has been carried out.

Check what the add-on can do in your account

The term “customer portal” covers different capabilities. HubSpot's customer portal documentation describes access to tickets after login. Conversations that are not associated with a ticket do not appear in the documented portal. It also describes visibility options for tickets associated with the user's own contact, their company, or selected contacts. Check these options against your specific account and workflow.

If customers mainly need to track tickets, an existing module may be a good fit. If they need to approve a particular document version, ask to walk through that approval during the walkthrough. A file list and a comment field do not establish whether the system records who approved which version or what happens when someone revises it later.

Ask the vendor to identify the required plan, settings, and additional modules. Distinguish a missing capability from one your company has not enabled yet. That gives you a realistic alternative to compare with custom software.

One customer request, several sets of permissions

Consider an illustrative B2B company that fulfills orders against an agreed specification. An employee at the customer company opens a case, downloads a document, and requests a change. An authorized colleague approves the final version. On the supplier's side, the account manager checks whether the change is feasible before updating the agreed details in the CRM.

The portal's initial scope can cover this one workflow. Sales, invoicing, and fulfillment planning remain in their existing tools. The customer should be able to see the current stage of the case and whether the next action belongs to them or the account manager. A change request needs a separate decision: submitting it must not appear to confirm a change to the order.

An employee might see their own cases while their manager can see cases across the customer company. Approval rights need a separate decision. Access to a document does not automatically grant authority to approve it on an organization's behalf. Establish who grants these permissions and what evidence they use to associate a new user with the customer company.

Extend the example to an employee leaving. Their access is revoked, but their requests and approvals remain in the case history. Their replacement takes over open tasks under rules agreed with the customer. During the walkthrough, check both the departing employee's loss of access and the replacement's ability to continue the unfinished case. This reveals more than a walkthrough using an administrator account.

When a smaller change is enough

After walking through the example, compare the available options. Configuring the current add-on makes sense if it can support the roles and workflow without constant workarounds. A plan change may unlock the required capabilities, but consider its effect on the full contract. Another ready-made product is worth assessing when the requirements are standard and the current vendor does not fit the way you work.

A small extension may be enough if only one step is missing, such as document approval. A custom portal becomes a reasonable candidate when you need to connect specific customer roles with information from several systems. It still needs a clear boundary defining which actions it handles and when it hands a case to an employee.

For this comparison, the article on maintaining a custom portal and retaining the option to change vendors may also help. It focuses on suppliers, but its questions about migration and ownership apply to a customer portal purchase as well.

The CRM and portal need to show the same case

Decide where the authoritative status is recorded and who can change it. If the CRM remains the main source, the portal should display its data with an agreed refresh frequency. When synchronization fails, the customer needs a clear message and the team needs a way to detect and handle the problem. A second, manually maintained status list adds daily work.

Migration does not have to include the entire history. You could agree to transfer open cases while leaving older materials in an accessible archive. However, check that documents remain linked to their versions and approval decisions. Before purchasing, also agree on the terms for future data exports, transfer of code and documentation, and handover of maintenance to another provider.

Acceptance testing covers both sides of the work

Evaluate the solution using anonymized cases, including a revision after approval and a change of approver. Acceptance criteria can describe behavior that you can observe:

  • A user from one company cannot access another customer's cases.
  • An approval identifies a specific document version and an authorized person.
  • A change request reaches the responsible account manager, and the customer can follow its status.
  • Revoking access prevents further use of the account while preserving the case history.
  • A data exchange failure is visible to the person responsible for handling it.

Alongside the features, assess the administrative work: inviting users, restoring access, correcting account assignments, and helping customers. A drop in email volume may mean some support work has moved to another channel. Savings depend on the total workload and ongoing maintenance cost. Freeing up staff time does not automatically produce cash savings.

What to bring to a scoping discussion

Syntalith builds custom software and applications, as well as automations and AI agents. For a portal, these capabilities allow the customer interface and any additional tasks to be assessed separately. AI may be useful for summarizing lengthy correspondence attached to a case, while statuses and approvals can work without a model.

Include an account of one case from start to finish in your inquiry, along with your CRM and plan and the roles on the customer side. Identify where email follow-ups recur and who will be responsible for the portal after launch. Depending on the agreed scope, the work can cover workflow design, integration, and acceptance criteria, together with maintenance arrangements. See Syntalith's pricing page for the current offer. Compare proposals against the same case workflow and the same level of ongoing support.

Assess whether custom software makes business sense

Compare your subscription, required features and workarounds with the cost of development, migration and ongoing ownership.

Explore custom applications
Discuss custom software