Why should an electronic invoicing service give its customers a panel?
An electronic invoicing provider holds documents that belong to its customers. If those customers cannot look them up by themselves, knowing where an invoice stands means writing to someone every time. For one of these providers we built that place: a React dashboard on the APIs the service already exposed.
Anyone who handles tax documents on behalf of other businesses ends up holding data that belongs to their own customers. Until those customers have somewhere to look at it, every question about the status of an invoice lands with support.
That is the case of an electronic invoicing service for businesses.
When the only way to know is to ask
Without a panel, finding out the status of an invoice or how much is left of your package means opening a ticket. The cost you can see is the time of whoever answers; what weighs more is that to check something of your own you have to go through someone else, on tax documents.
A dashboard on the APIs that were already there
The panel is a React dashboard resting on the APIs the service already had. The work was not writing one: it was deciding what the person who logs in gets to see, because on tax documents permission comes before the screen.
What changed
Status requests and changes to subscriptions are resolved inside the panel, without reaching support.
Who opens the panel
A panel like this one is opened by the customers of whoever commissioned it, not by its employees. That changes who has to be listened to when deciding what to show, and it changes what happens if a screen is ambiguous: the question comes back in the form of a ticket, which is where it all started.
It is custom web app work.