arendalsoftware engineering

SolutionsCustom software

Client portals and web apps

Customers do online what they currently phone or email you for.

How we deliver it

  • We find the requests your staff handle by hand most often.
  • We build the portal or app that lets customers do them directly, writing back to your systems.
  • An existing portal is migrated piece by piece, without taking it offline.

How it works

A portal earns its keep by taking work off your staff, so we start from the requests they handle by hand most often. For each one, the customer should be able to do it themselves, with the change written straight back to the systems your staff already use, not into a separate inbox.

WHAT YOU HAVEAPPROACHTRADE-OFFA system witha portalStandardself-serviceA workflow ofyour ownSwitch onits portalPortalplatformCustom portalor appQuick,within itslimitsFast,per-user feesFits exactly,yours to keepA system witha portalStandardself-serviceA workflow ofyour ownSwitch onits portalPortalplatformCustom portalor appQuick,within itslimitsFast,per-user feesFits exactly,yours to keep
What you already have decides the approach.

What changes for customers and staff

The request that used to be a phone call, retyped and confirmed days later, is made online, lands in your systems directly, and is confirmed on the spot. Your staff see the change without doing anything.

BEFOREphoned inAFTERdone onlineCustomerphonesStaff retypethe requestChangedlaterCustomerwaitsCustomerportalWritten toyour systemsStaff seeit at onceConfirmedat onceBEFOREphoned inAFTERdone onlineCustomerphonesStaff retypethe requestChangedlaterCustomerwaitsCustomerportalWritten toyour systemsStaff seeit at onceConfirmedat once
One customer request, before and after.

Replacing a portal that is already live

When there is an existing portal, nobody gets a big-bang cutover. The old one keeps running while features move across one at a time, and it is retired only when nothing depends on it any more.

STAYS UPONE FEATUREUSERS MOVEREPEATRETIREOld portalkeeps runningOne featurerebuiltUsers movedgraduallyNextfeatureOld portalretiredOld portalkeeps runningOne featurerebuiltUsers movedgraduallyNextfeatureOld portalretired
Migrated a feature at a time, never offline.

What decides it

Which requests first
The ones staff handle most often by hand. Two or three of them usually account for most of the calls.
How customers sign in
Their own accounts, with password resets and two-step verification that do not need your staff. Account security is part of the portal, not an afterthought.
What customers may see and change
Each customer sees only their own records, and some changes may need a person to approve them. These rules are decided before any screen is designed.
Web, app or both
A mobile app is worth it when customers come back often or need the phone itself, such as its camera or notifications. Otherwise a web portal that works well on a phone is enough.
What it must talk to
Every change should land in the system that owns it. That is integrations, done properly.

Hand over or run

Your choice, per solution. We hand it over with documentation your team can work from, or we keep it running: upgrades, monitoring and incidents, with one of us on call 24/7.

Proof

We built the web API behind a customer-facing application, adding the write path the platform had never had.

Talk to the person who builds it

Tell us what is slow, stuck, or held together by a spreadsheet. We will tell you what we think in one call, before any proposal.

DanielCo-Founder

daniel@arendal.ca