Customer Portal

The customer portal is the surface an end user at a client company signs in to. It lives at /user and shows one person their own requests, their own devices, their company’s invoices and quotes, and the help articles published to them.

It is deliberately narrower than the organization and MSP portals: nearly everything in it is either personal to the signed-in person or read-only.

Who it is for

The portal a person is in — not their role — decides what the backend returns. When anyone is in the customer portal, the API pins them to their own requests, their own assigned devices and the projects they are a member of. An organization administrator who switches into /user sees the same personal view a CUSTOMER does; switching back to /org restores their administrative reach.

Concepts

Request statuses as the customer sees them

Navigation

Notifications open from the bell; the profile page from the avatar menu; the Sol assistant from the panel trigger or Cmd/Ctrl + K.

Walkthroughs

Raise a request

1. Home → Report a Problem (or My Requests → New). Both land on /user/requests/new.
2. Pick a category, then a common request (for example Accounts & access → I’m locked out). The type, category and priority are pre-filled from that choice.
3. If nothing fits, choose Can’t find it? Describe your issue and type it. Once the description settles, the portal searches the help centre and offers up to three articles that might resolve it without a ticket, and the AI assist offers a category and priority you can apply.
4. Attach files if you need to. Anything over 16 MB is listed as too large rather than dropped in silence.
5. Submit request. The portal creates the ticket, uploads the attachments, and takes you to the request page. If a file fails to upload, the request is still created and the page tells you which files to re-attach.

What happens behind the request:

• The organization’s SLA policy for that priority is applied, so response and resolution deadlines exist from the first second.
• Queue routing runs — first any matching routing rules, then the organization’s default queue, then the servicing MSP’s.
• The queue’s members get an in-app notification.
• A TICKET_CREATED webhook fires and any TICKET_CREATED automation rules run.
• The requester gets a “We’ve got your request” email with the ticket number and a link, unless they have turned email notifications off.

Report a problem with a specific device

1. My Technology → a device → Report an Issue with this Device.
2. The composer opens with the device named at the top of the form.
3. Submit. The ticket is created with that device attached, so the technician sees which machine is broken. The device chip appears on the request detail page, and the device’s own page lists the request under Recent Requests.

Only devices assigned to you can be attached. An id you do not own is dropped rather than rejecting the whole request.

Follow a request to the end

1. My Requests → a request. The page shows a progress stepper, the conversation, the attachments and an activity tab.
2. Reply in the composer. Your reply notifies the assignee (or, if nobody has picked it up yet, the queue), fires a TICKET_COMMENT_ADDED webhook and pushes a live update to anyone with the ticket open. If the request was Needs your reply, it moves back to Being reviewed so it re-enters the service desk’s queue.
3. When the technician resolves it, you get an email and the page offers Approve & close or Reopen.
4. After closing, rate it 1–5. The rating is stored against the ticket and feeds the CSAT reporting your MSP sees.
5. At any point before resolution you can Cancel request to withdraw it.

Pay an invoice

1. Billing. The Invoices tab opens with a total outstanding and the number of invoices due, both computed server-side across every invoice, not just the page on screen.
2. Pay invoices opens the payment wizard: choose the invoices, choose a saved card or enter a new one, confirm.
3. Deleting a saved card or changing which one is the default is an administrator action — those two controls live in the organization portal.

Accept a quote

1. Billing → Quotes → Review & accept. The list takes you to the quote itself; a quote is not accepted from a list row.
2. Read the quote. Opening it is what moves it from Sent to Viewed, which is the state the backend requires before it can be accepted.
3. Toggle any optional line items you do or do not want.
4. Accept, then type your name and signature. Both are stored on the quote as the acceptance record.
5. Decline instead if you need to; a reason is required.

Sign a statement of work

1. Projects → a project → SOW.
2. Only statements of work that have been sent appear. Drafts and internal reviews are the author’s working copy and are not visible here.
3. Open it, read the scope, deliverables, timeline and payment terms, and accept or decline.

Export or erase your personal data

1. Privacy.
2. Request a copy — choose JSON or CSV. The export is generated in the background; the row moves to Completed with a Download button. The download is authenticated, so it only works while you are signed in, and links expire after 7 days.
3. Request erasure starts the deletion workflow and can be cancelled while it is pending.
4. Consents lists what you have agreed to and lets you withdraw any of it.

Configuration

Notification preferences (/user/profile → Notifications)

Transactional mail — password resets, invoices, signing requests — is not governed by these switches. Those are documents you asked for, not notifications.

The Save button is disabled until your current preferences have loaded. This is deliberate: the write replaces the whole enabled-types list, so saving from a half-loaded page would silently switch off everything you had not touched.

Calendar sync (/user/integrations/calendar)

Connect a personal Microsoft 365 calendar, pick which calendar to sync, choose the direction and frequency, and optionally subscribe to real-time updates. Every action reports its own failure — a missing MICROSOFT_CLIENT_ID on the server surfaces as a message rather than a button that quietly does nothing.

Two-factor authentication

Not self-service in this portal. The profile page links to the request composer so you can ask your IT team to enable it.

Plan tiers

The customer portal itself is not sold separately — it comes with every end customer tier. The tiers change what the portal can do around the edges:

Running out of AI credit does not break the portal: Sol answers with a message naming the limit and pointing at the administrator, and every other surface is unaffected.

Troubleshooting

Limits and known behaviour

• One person, one view. Requests, devices and projects are pinned to the signed-in person, not to the organization. There is no “everyone’s tickets” view in this portal; that is what the organization portal is for.
• Read-only by design. Sites, network/IPAM, project tasks, milestones and status reports are all read-only here. The controls that would write are not rendered, and the routes behind them are floored at organization administrator.
• No reporting. /user/reports redirects to the dashboard. Every report surface aggregates an organization’s tickets, assets, invoices and headcount, which is not a customer-contact view.
• Comments are always public. A reply from this portal is always a PUBLIC comment; there is no internal-note level available to a customer, on read or on write.
• A reply does not stop the SLA clock. The first-response clock is satisfied by a staff reply. A requester chasing their own ticket leaves it running.
• Attachments cap at 16 MB per file in the composer.
• Saved cards are shared. Reading them is open so the pay flow works; changing the default or deleting one is an organization administrator action, because it affects the whole organization’s autopay.
• Two-factor is not self-service in this portal.
• Personal Calendar is the only user-level integration currently seeded, so it is the only card the Integrations page shows.