Let's talk
data-modelling

I sent a notice to one region and the wrong staff got it

A region-wise notice reached 11 of the 500 people it was meant for. Two different lists of regions shared one name, and the form wrote one and read the other.

·

A monitor on a desk in a warehouse showing the Sazinga Field portal dashboard that a manager uses to reach regional staff.

You write a notice for your staff in one region and pick that region from the list. The notice saves without complaint. Then a back-office colleague tells you the region-wise notices are not reaching the right people.

They were right, and it was worse than a few misses. When we measured who received what against who the notice was meant for, only 11 of the 500 intended recipients got it. Two per cent. And 247 back-office accounts were being sent the unfiltered list of every notice, region or not.

What was actually going on

The company behind this, Aries Agro, a crop-nutrition manufacturer, keeps two entirely separate lists of regions, and the database gives both the same column name. One is the business list, the sales regions the company is organised into. The other is geographic: the regions that states and pincodes belong to.

The portal’s region picker was fed by the business list. No lookup existed for the geographic one. So five admin forms, for notices, users, dealers, depots and push notifications, showed business-region labels to the person filling them in, and saved the choice into columns that refer to the geographic list.

The mobile app then filtered by the geographic region on the employee’s profile. The form had written one kind of region and the app was reading the other, and nothing connected them cleanly.

There were two smaller failures on top. The notice list filtered by region only for three specific roles, so every back-office account fell outside the filter and got everything. And 370 employees had no region on their profile at all, so they could never see a region notice.

We checked which column could be trusted before proposing anything: the profile region agreed with the employee’s state for all 575 of 575 employees who had one.

What is still open

We have not fixed this. The work was a diagnosis and a decision. We documented two routes: make the forms offer the business regions and truly target by them, or make the forms offer the geographic regions the app already reads. Both need the client to choose.

What we did produce is a mapping file from the client’s employee export that supplies the missing business region for all 377 employees who had none, so either route starts with clean data.

What it did not fix

Until one of the two routes is chosen, a region-wise notice is still unreliable, and the state selector on the same form is also broken.

The pattern, for anyone who groups staff or customers by region

Ask how many different meanings “region” has in your business. Sales region, state, depot area and delivery zone are often four lists. If two of them share a name in your software, a form can quietly save one and a filter quietly read the other.

Then send a test notice to one small region and count who received it. That count takes minutes.

Where this ends up

Sazinga Field depends on one agreed definition of region for the field team, and choosing it is the decision this case is still waiting on.

This came out of building Sazinga Field

Orders, stock, dispatch and the people on the road, in one place. The problem above is one we met while building it, and what we did about it is in the product.

If you run something like this, there is one thing you can do without a call: send one day's order sheet.