I think you don’t get what I’m saying. I’m not asking for a single database to be shared between Samba & Gloria to achieve a full integration, all I’m asking when samba pulls the data from Gloria to do it in separate fields.
Currently it pulls it all in a single field:
[First Name] [Last Name]-[Phone]
[Street Address], [PostalCode], [City]
I’m asking to to be pulled in separate fields:
[First Name]
[Last Name]
[Phone]
[Street Address]
[City]
[PostalCode]
Currently Samba receives the order and checks the entire [First Name] [Last Name]-[Phone] to see if the customer is already an existing customer record.
If lets say this new customer places a phone order (not gloria) for the first time, staff receiving the order will have to enter [First Name] [Last Name]-[Phone] the risk of making a mistake is quite high.
So it is best for Samba to compare [Phone] only, there is less likely chance to make a mistake in just a phone number.
Hope that makes sense, if not maybe we should have a phone chat.
It does put it in separate fields. FirstName, LastName, Address, and Email we can add Phone and other things. But the primary field will probably stay as is. We had people with different names but same phone number making phone as primary field impossible to create 2 separate accounts for the two people.
I understand why you are doing that with primary field.
Technically we need to have:
Primary field (already has first name, last name and phone)
First Name
Last Name
Phone
Address
So to be able to use other features such as SMSing upon delivery(Dear FirstName, your order is on the way), then we have to have first name on a separate field to primary field which means it will have to be entered twice. Unless there is a way to auto populate the Primary Field from other fields.
We have that now. It already populates those fields. FirstName, LastName, Address, Phone, Email are already there. You don’t have to use Primary field for those things.
I totally understand you. However we have a lot more people using it and they all use it differently. But it doesn’t mean we won’t improve it in the future.
I do understand you. You want them to match between systems which we can do now however you do not want your employees having to enter FirstName LastName - Phone format as they will make a mistake.
We can force them to that format through automation, there will still be possibility of mistake, misspelled name, wrong number.
Yes for your specific use case it would be easier to just make Phone the primary field. Maybe the best answer would be let the end user define primary field format with a setting in Sambain. I will suggest that and see what we can come up with.
We need a solution that can fit everyone’s desired use case not just one persons hence our issue. If we can make primary field a choice in Sambain settings that might solve this.
My customer entity type is default. It uses Name as primary field. Then has FirstName, LastName, Email, Address, Phone fields. In my templates I use {ENTITY DATA:Customers:FirstName} {ENTITY DATA:Customers:LastName} {ENTITY DATA:Customers:Phone} fields where I need them. I do not use {ENTITY NAME}
So for example when I send a text to a customer it reads {ENTITY DATA:Customers:Phone} to get just the phone number and then it sends a message Hello {ENTITY DATA:Customers:FirstName} your order is on the way and {ENTITY DATA:Deliverers} will be delivering it to you.
I do not use default customer search widget… i built my own automation for entering customers. It asks for First Name, Last Name, Phone and automation combines it into the primary field format to match GF. If customer is already existing it just selects that customer.
I prefer my system I feel its faster as the employee never has to leave the screen they are on, it just pops up.
No I built it from my learning and trial and error from using the system. Its a personal configuration I use in my own restaurant. I am working on another project right now and am not at the restaurant to share it. If I have time (which is very rare for me) I will try and share some of it.
Nothing in it is very advanced. You should be able to figure out how to do most of it by looking through forum. For example you can find how to use the Change Ticket Entity Action and how to use [?Prompt]
ok thanks, I must say I’m a little frustrated that this hasn’t been addressed. I know you have been trying to help. But i’m also confused on when to contact support and when to search a forum.
I fully agree with you @compwize the way the GF integration works with putting name and number into the primary field means you can’t easily use SambaPOS built in customer search anymore as you’d have to enter the name and number if you manually add for example say a phone order for new customer. Also wouldn’t work well with caller ID.
I do understand the reason behind why it was like that, but it would be better implemented by having additional fields to store multiple name / number or multiple address. This could of course be added yourself but with some work and would be difficult to use with the GF integration.
I do wonder however how many people really had an issue with different names from same number. I can accept different addresses from same number is more realistic, but different name from same number is only really going to happen if customers call from an office or similar place, as these days most people would put in their mobile number rather than landline.
I would like to see more flexibility in this with the GF integration as doing like it is currently means anyone who really wants to use for phone orders as well as GF it makes it not an out of box solution, which it should be especially when it can be purchased directly (ie not only by resellers).
In the USA its very common… Happens everyday at my location as well as the other locations I personally deployed. I cant speak for other countries though.
It’s not common in the UK. Probably as mobile plans are much cheaper here everyone tends to use mobile. We see more of people ordering same number and name but different address (like friends house etc)
Yeah I think so then it lets you choose how you want to do it. Making a decision like this for them could be really disastrous - imagine someone using sambapos for many years then installed sambain it’s going to make a total mess of their data!
I agree with @markjw how often would you have a mobile number with multiple contacts? and if so, that wouldn’t be as important as the issue we are currently facing. Double entering a filed multiple times is high price to pay for the few times a day multiple names with same mobile number.
Most customers will use a mobile number for ordering, if a wife calls with the husband’s mobile then who cares really. My customer I’m implementing the solution for has 5000 customers, only 100 using landline number with multiple contacts (police stations etc).
Don’t get me wrong we love using Samba but little things like that is so simple to make it out of box solution.
The solutions should be as easy as making the Primary Field customisable so we can have it auto populate itself from single fields.
And what is really more troubling, that we will have to rebuild the customers database once you address this in the future. If you implement a fix for this issue then most likely, customer’s database will need to be re-imported with the correct fields.
My point is I understand you and I am not saying your wrong. Obviously we need to find a better solution. But just changing primary key fixes your problem but starts another with other setups. We need to find a better solution for everyone.