Customer portal or email? Start with the repeated request.

List the requests customers repeat

Start with actual customer conversations rather than a list of portal features. Review the questions your team repeatedly answers and the information customers regularly need to send, receive or confirm.

Look for a bounded task with a clear beginning and end. Status checks, approved document exchange, profile updates or service requests may be candidates. A vague goal such as putting everything online is not yet a workable scope.

• What is the customer trying to learn or complete?
• How often does the same request occur?
• Which information must staff review before it is shown?
• What should happen after the customer responds?
• Who owns the request when it needs judgement?

Check whether clearer email is enough

Email can remain appropriate when requests are occasional, the conversation needs judgement and the customer does not need a continuing account. A consistent subject line, template, responsible person and filing rule may remove confusion without adding another place to sign in.

Do not assume that a portal is automatically more secure or that email is automatically unsuitable. The information involved, access controls, selected tools and operating process all need assessment.

• Can staff find the latest approved version without searching several inboxes?
• Can a customer tell which message is current?
• Is one person responsible for the next action?
• Would a shared status view prevent a genuinely repeated question?
• Will customers use an account often enough to justify maintaining it?

Define the smallest useful portal

If email no longer fits, choose one customer job for the first portal scope. State exactly what a signed-in customer can see, submit, change and download, and what still requires staff contact.

An illustrative first stage might let a customer view an approved service status, upload one requested file and send a question connected to that record. This is a planning example, not an 1120 client case study or a promise that a particular integration is available.

Separate customer-visible information from internal work

A staff record may contain internal notes, draft decisions, assignments or information that should not appear in the customer view. Define customer-visible fields deliberately instead of exposing an internal screen with a different layout.

For each status or document, name who may publish it, who may correct it and when the customer should be notified. A portal should not turn an unfinished internal update into a customer commitment.

• Customer-visible status and plain-language explanation.
• Internal status, notes and responsible staff member.
• Approved documents versus working drafts.
• Customer-submitted information awaiting review.
• Notifications that contain only the information needed for the next step.

Test accounts, permissions and corrections

Use fictional or specifically approved test data. Create at least two customer accounts and confirm that each account can access only its intended records. Test an incorrect link, an expired session and an attempted change to a field that should be staff-controlled.

Decide how identity is confirmed, how access is recovered and how a mistake is corrected. These checks help define requirements; they do not establish legal compliance or guarantee security.

Choose the authoritative status

When the portal, inbox, CRM or another working tool shows different information, staff need to know which record controls the next action. Document where the approved status lives and how other views are updated.

Test a change made by staff and a request submitted by a customer. Confirm that the right person sees it, the customer sees an appropriate result and a failed update does not silently leave two conflicting versions.

Plan support, removal and fallback

A portal creates ongoing responsibilities after launch. Decide who helps a locked-out customer, removes access when a relationship ends, corrects account ownership and responds when a connected service is unavailable.

Agree how needed records can be retrieved or exported and what the customer should do during an outage. Confirm retention, privacy and access requirements with the appropriate advisers for your business and information.

• A monitored support route for access problems.
• A process for closing or transferring an account.
• A manual way to receive an urgent request.
• A visible owner for failed notifications or updates.
• A documented recovery check before normal operation resumes.

Pilot one complete customer journey

Run a small pilot that covers invitation, sign-in, the main customer task, staff review, correction and access removal. Record both the steps that work and the places where someone still needs another message or spreadsheet.

Expand only after the first journey is understandable to customers and supportable by staff. This evaluates the workflow itself; it does not forecast revenue, time savings or customer adoption.

Discuss the portal scope with 1120

1120's published services include customer portals, custom business software, business websites, lead and CRM automation, and booking and email workflows.

Bring one repeated customer request, the information customers should see and the internal steps that must remain staff-controlled. Specific integrations, access requirements and project deliverables need assessment before they are committed.

Start with your business process.

Describe how customers reach you and what your team needs to do next.

Explore 1120 capabilities