OpusBUSINESS EXPERT

Your biggest customer's portal means you now run two systems

Andy Shepherd7 min read
  • Technology
  • IT consultancy
  • Systems integration
  • Warrington

The email arrives from procurement and it is not an invitation. From the first of next month, orders, delivery notes and invoices go through the portal. There is a link to a registration page, a PDF of instructions written for a company forty times your size, and a deadline.

Nobody negotiates, because the account is too big to lose. So somebody in the office starts entering every job twice: once in the portal, once in the system the business actually runs on.

That works. It goes on working for months, which is the problem. It is a common shape around here, among the Warrington and mid-Cheshire manufacturers and trades whose customer list includes one or two organisations far larger than they are.

Double entry is not what hurts you. Drift is

Typing something twice is annoying and measurable, and if that were the whole cost this would be a short piece. The damage comes later, when the two records stop agreeing and nobody notices which one moved.

Their purchase order number never makes it onto your job. Six weeks later they query an invoice by quoting that number, and there is no way to find the job from their reference without somebody remembering.

Their delivery date and your schedule diverge. Neither is wrong. The portal says what they asked for, your planner says what your fitters are actually doing, and the two were last reconciled by a phone call nobody wrote down.

An invoice bounces on a mismatch you cannot see from your side. A unit of measure, a site code, one line more than the order carried. The rejection message tells you almost nothing, because it was written for a supplier with a procurement department of their own, and you are now two weeks further from being paid than you thought.

The reliable symptom is that "what did we agree to deliver, and when" now has two answers, and settling it takes a person rather than a screen.

Before anything else, count it

This decision is arithmetic, not principle, and most firms argue it as principle.

  1. 01Measure the re-keying for one real week, with a clock, rather than estimating it
  2. 02Count how many invoices to that customer were queried or rejected last quarter
  3. 03Work out what those queries cost in days waiting to be paid
  4. 04Only then ask anyone what an integration would cost

The first number is usually smaller than the office thinks and the second is usually larger. Forty minutes a week is about thirty-five hours a year, which is real but is not a software project. Four rejected invoices a quarter, each sitting three weeks longer than it should have, is a different kind of number and it is the one that tends to justify doing something.

We sell systems integration, so it is worth saying plainly: for a good many firms, double entry is cheaper than the integration and stays cheaper. If one person spends half an hour a week on this and nothing ever bounces, leave it alone. That is a complete answer and we give it often.

The three ways out, in the order to consider them

Decide which copy is the master. This costs nothing and fixes most of the drift, because the drift is rarely a technical failure. It is the absence of a decision. Write down which record is authoritative for each fact: their portal for the order and the reference number, yours for scheduling, materials and cost. Then make the other one downstream, so a change in the master is what triggers the update rather than two people updating whichever screen is in front of them. Half the firms that ask us for an integration need this instead, and find out in an afternoon.

Integrate, if there is anything there to integrate with. This is the step people skip, and it is where the money goes.

A surprising number of supplier portals have no supplier-facing interface at all. Others have one, but only for suppliers above a volume you are nowhere near, or only as a paid add-on that costs more than the re-keying it removes. That answer is free and it takes one email, and it is the single most useful thing to establish before anybody quotes you anything.

If the answer is no, do not let someone talk you into automating a login and scraping the screens. It breaks the first time they change a button, and driving a customer's portal with a robot is a good way to have your access looked at. Ask them before considering it, and take the answer seriously.

Stop keeping your own record for that customer. The option nobody offers, because it does not involve buying anything. If that one account is most of what you do, you can accept their portal as the system for their work and stop maintaining a parallel copy of it. You lose your own view of that work, which is a genuine cost and is why this only makes sense when one customer really does dominate. It is still the right answer more often than it gets suggested.

What an integration actually has to reconcile

If you do end up building one, this is the list that decides the price, and it explains why two quotes for the same job can look nothing alike.

Identity comes first. Their part codes are not your part codes, their site codes are not your delivery addresses, and somebody has to own the mapping and maintain it as both sides add items. That table is the project, more often than the connection is.

Then the reference has to survive the whole journey, from their order onto your job and back onto your invoice, or you have rebuilt the original problem with more steps in it.

Then amendments. They will change a purchase order you have already started work against, and the system has to have an opinion about what happens next rather than silently overwriting your record.

And failure. A connection that stops working loudly is an inconvenience. One that stops working quietly, posting nothing for nine days while everyone assumes it is fine, is worse than the double entry you replaced. Somebody has to be told, and that somebody has to be a person rather than a log file.

70%
Software spend cut for one client by making existing tools earn their keep
1
Master record per fact — the decision that costs nothing

We built the one-record-many-surfaces thing properly in our own platforms, where a client record has to hold still while a portal, a mobile app and a staff screen all look at it, which is why that list is from experience rather than from a brochure. It is also why we are comfortable telling people the connection is not the hard part.

The framework underneath

Whether to replace a system or integrate it is a test we have written up before, and it applies here with one difference that matters: this system is not yours. You cannot replace it, you did not choose it, and it will change without asking you. Anything you build against it is a standing commitment rather than a finished job.

Which puts the weight back on counting. The same three numbers that decide whether a job is worth automating decide this one: how often, how long, and what a mistake costs.

If you have just been put on a customer's portal and the admin has visibly doubled, the first conversation costs nothing, and "decide your master record and leave it at that" is an answer we give more often than the other one.


We work with businesses across Knutsford, Alderley Edge, Wilmslow, Altrincham, Stockport and Warrington, and remotely for clients anywhere in the UK.

If any of this sounds like your business, we will tell you plainly whether we can help.

We would like to use analytics cookies to understand how this site is used, advertising cookies to measure our ads, and to load our office map from Google. None of them loads on its own unless you accept — though Google Tag Manager itself loads either way, with every category switched off. The map also has a button of its own. Read our cookie policy