Who You Are Actually Selling To
A customer here can have many named contacts with roles, and many structured addresses with labels and a default. It is a proper counterparty model. It also has a second, free-text address field on the customer itself — so there are two places an address can live, and only one of them is the one your team will fill in.
A customer is rarely one person at one place. The person who orders, the place the goods go, and the person who pays are frequently three different things, and a system that models a customer as a name and an address is quietly wrong about all three.
What the model actually supports
More than most products in this bracket, and it is worth listing because almost nobody uses it.
Many contacts. Each with a name, a role, an email, a phone, a mobile, and a flag marking one as primary. So the buyer, the person in accounts and the person at the gate can all be on the record, distinguished by role rather than by whoever typed them in first.
Many addresses. Each structured — line one, line two, city, state, postal code, country code — with a label and a default flag. So a registered office, a warehouse and a site can all exist as separate, properly structured records rather than as three lines in a text box.
That structure is the part that matters. A country code you can filter on is a different thing from a country name somebody typed, and a labelled address is a different thing from an address with "(delivery)" written after it.
The capability is there. The habit is not, because the simpler field is right in front of you.
The second address
The customer record itself also carries a plain free-text address field, alongside coordinates.
So there are two places an address can live: the free-text one on the customer, and the structured ones in their own records. Both work. Both are filled in. And the free-text one is on the main form, which means it is the one that gets used.
The consequence is predictable and it is worth deciding about before it happens rather than after. Six months in, half your customers have a delivery address in the free-text field and half have it as a structured record, and no report can see both.
| Where the address is | Structured? | Multiple? | Filterable? |
|---|---|---|---|
| The customer's own address field | No — one line of free text | No | Not usefully |
| A customer address record | Yes — line, city, state, postcode, country code | Yes, with labels and a default | Yes |
| A warehouse's address | No — one line of free text | No | Not usefully |
The third row is included because it is a fair thing to know: the structured-address capability exists on the customer side only. Your own warehouses have the simple kind.
Why this matters in a market where the buyer is not the receiver
Bangladeshi trade — in the garment and textile chain particularly, and in distribution generally — routinely separates the three roles a naive customer record collapses into one.
A buying office places the order. The goods go to a factory or a warehouse somewhere else entirely. The payment comes from a third party, sometimes in a different country. And the person who will actually chase you about a delayed delivery is none of those three.
With one contact and one free-text address, all of that lives in a notes field and in somebody's inbox. With roles and labelled addresses, it lives on the record, and it survives the salesperson leaving — which is the whole point of a customer master and the reason it is worth the extra minute at data entry.
What the structure does not reach
Two boundaries, and both are about what happens after the data is captured.
A default address is a default on the customer record. There is no delivery note for it to print on, because there is no delivery note — see The Document That Goes With the Goods. So the labelled delivery address is reference information rather than something that flows onto a document a driver carries.
And a contact with a role is not a login or a portal user. Suppliers get accounts in this product; customers do not. A contact is somebody you know about, not somebody who can see anything.
What AWRA OpsHub does today
- Multiple contacts per customer, each with a name, role, email, phone and mobile, and one flagged primary.
- Multiple structured addresses per customer — line one and two, city, state, postal code and country code — each with a label and a default flag.
- A customer record carrying a company name, personal names, country, currency, credit limit, status, notes and custom fields.
- Coordinates on the customer, so a location can be plotted rather than only written.
- A per-customer tax profile including registration details and an exemption that is honoured in tax resolution.
What it does not do
- Any customer group, tier, segment or parent-child relationship between customers.
- A customer login or portal. Contacts are records, not users.
- Any document that prints a labelled delivery address, because there is no delivery note.
- Structured addresses anywhere other than customers — a warehouse has one free-text line.
- Deduplication or merging of customers created twice.
Not ours, by choice
- Two places an address can live is the practical risk here, and it is a data-entry discipline rather than a defect. Decide which one you use before go-live.
- The structured model is genuinely better than most in this bracket and is under-used precisely because the simpler field is more visible.
- Nothing here is Bangladeshi. It is what happens when the buyer, the receiver and the payer are different parties; this is a market where they usually are.
What is not built for your market today can still be built for you
Anything described above as not built is a statement about what ships in the standard product today — not a limit on what AWRA OpsHub can do in your market. Kenya's eTIMS integration and its maintained payroll engine exist because Kenyan clients needed them and commissioned them; neither appeared by itself. The same door is open here. If a tax authority pipeline, a bank or mobile money feed, a statutory return format, a rule your own operation needs that the standard one does not have, or a link to a system you already run is what stands between you and a decision, tell us and we will scope it as a build — written spec, timeline and price — before you commit to anything.
Tax authority pipelines and reporting
Electronic invoicing or invoice registration against your authority's published interface, with retries, a failure queue and a daily report of sales that carry no reference. The regimes across this region differ enough that this is one build per country rather than one build for the region, and the local bench is deep in most of them — so the honest question is usually whether you need this from us at all, or whether you need the operations layer that feeds whatever you already file with.
Local payment rails and bank feeds
Real-time payment collection matched to the invoice, bulk payment files in your bank's format, and statement feeds wired into the Payments Register.
The operational work, which is what most commissions actually are
An extra approval stage in a chain that does not match the standard one, a custom field set on employees or assets that only your sector needs, an expiry that has to block an order rather than send an email, a report your board asks for in a shape nothing produces, or a scanner or weighbridge feeding the goods-in door. These are the commissions we are asked for most often and the smallest ones we quote — and unlike a revenue-authority pipeline, none of them waits on a regulator.
Payroll and statutory returns
Statutory payroll and social security schedules computed on live records and produced in the layout each filing body expects. Per-state and per-province variation is the norm rather than the exception here, and it is what makes this a country build rather than a regional one.
Systems you already run
The accounting package, CRM, online store or custom database you intend to keep — connected through our API so a fact is entered once and appears everywhere it is needed.
How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. No roadmap slide, and no pretending in a demo that something exists when it does not.
Tell us what you need integratedThree questions about a customer master
How many addresses can one customer have, and are they structured?
A good answer sounds like
Many, with fields rather than a text box.
What it actually means
Ours supports many and structured, and also has a free-text one. Ask about both, because the second is where the data will actually go.
Can I tell the buyer from the person in accounts?
A good answer sounds like
A role on each contact.
What it actually means
Without roles, a contact list is a phone book and the collections team is guessing.
What happens to the default delivery address on a document?
A good answer sounds like
It prints on something.
What it actually means
Ours prints on nothing, because there is no delivery note. A structured address that never leaves the screen is reference data, not operational data.
Our position
Use the structured contacts and addresses — they are better than most systems in this bracket offer, and they are the difference between a customer record and a phone number. Then make one decision before go-live and write it down: whether the customer's own free-text address field is used at all. Two places for one fact is how a good model becomes an unreliable one.
Decide the address rule before you load anything
One sentence in your data standard — structured records only, free-text field left empty — and your customer master stays queryable for years. We will help you write it.
Set the standardFrequently asked questions
Should I use the free-text address field at all?
Our advice is no — use structured address records for everything, including the main one, and leave the free-text field empty. It is the only way a report or an integration can rely on finding an address in one place.
Can a contact receive documents directly?
Contacts are records rather than users, so there is no customer login and no portal. Where a document is emailed, it goes to the address you send it to; the contact list is how your team knows which address that should be.
Can two customers be merged?
There is no merge, so a customer created twice stays twice, with history split across both. That makes the discipline at creation more important than it looks — a duplicate is cheap to prevent and expensive to live with.
