Address Book

[burt]

I have recently been wondering about the ability in this software to have;

 

- account address

+ multiple shipping addresses

+ multiple invoicing addresses

 

Could any shops get away with having customers have 1 address for everything ? IE, shipping, billing, main address all the same.

 

Do any shopowners have stats regarding how many orders have addresses on them other than the main account address ? Thanks

[mhsuffolk]

I have had an OSC site since 2009. In my experience about 5% of customers specify an alternative delivery address. I think this is because in the UK, house number and Postcode numbers are checked against their card records when they go, in my case to Worldpay or PayPal. Also when my customers order more than four of my DVDs they will not go through a normal house letterbox so they have them delivered to their place of work.

[azpro]

I don't have stats .. Shop running over 10 years .. I estimate about 5 to 10% use different addresses. What I do see (using who's online) is confusing about the different addresses ... So for 2.3.4BS I recoded the functionality... But not yet live so no conclusions...

 

What I do think could be a different and more useful option (we have a lot of business buyers) is one account with different buyers / mail addresses ... But that' s probably off-topic for now!

 

Conclusive .. For me too early to drop the possibility for different addresses.

[♥bruyndoncx]

About 10% has 2 addresses for the same customer record and 1% has more than 2.

My stats are slightly higher, but that is because people corrected

and added their house number for the delivery address which they forgot at first.

 

select count(*) from address_book
group by customers_id
having count(*) > 1

or if you rather use the first/lastname combo

select count(*), entry_firstname, entry_lastname from address_book
group by entry_firstname, entry_lastname
having count(*) > 1

 

changing having count(*) = 1, you find the single entries

[♥bruyndoncx]

i have no need for multiple invoice addresses, but shipping is typically home / neigbour / mother or work address

 

I think storing an alternate shipping address on the order is fine, could even do with a UI that would find the previous shipping addresses and pick from that list without having to maintain a true addressbook

[Bob Terveuren]

Hi Burt
 
In my own experience (mainly payment modules) is that the billing address provided to the card companies may need to match their records for the cardholder - so the main account address can == billing address  == a single option that can be changed by the account holder in the account pages. 
 
Shipping address should have multiple options as folks will often want 'stuff' delivered to friends/relatives/sycophants and so on (e.g. amazon where us lazy b'stads can dropship gifts willy nilly every year when we forget 'that' birthday again).
 
So the address book would need to remain for shipping I guess.
 
On the other hand.......
 
Here's the data for two sites I have access to - Site 1 is USA only, Site 2 is International - table below shows the % found using the sql queries from Carine. Total customers around 52,000 with average 17.2% having more than one address book entry.

 

[edit]

Ahhhh the feckin' text input mongs a table? Try this:

[edit]²

That failed too - gosh! OK here goes

 

                                                Site 1                      Site 2

Total customers                     24885                     27618

Using customer_id                   4291                       4503

Using first/last                          4393                       4850

 

Average                                              17.19%

 

 

 

 

 

 

 

[piernas]

In my case 8% of the customers have more than one address. Almos in all cases I've seen the same address with corrected data, so it seems people tend to add another address instead correcting the faulty one. Just very few rare cases used different addresses for shipping and for billing.

 

Here's what I found abut this matter: http://www.oscommerce.com/forums/topic/407485-ordering-process-question/

[burt]

I did it a bit different, this maybe gives a more useful result, thoughts?;

 

Site #1, 57387 orders, this site is in a similar business to @@bruyndoncx

SELECT count(*) FROM `orders` WHERE `customers_street_address` != `delivery_street_address`
gives: 4251
or 18.08%

SELECT count(*) FROM `orders` WHERE `customers_street_address` != `billing_street_address`
gives: 722
or 1.25%

Site #2, in a *very* niche market, number of orders = 2822;

SELECT count(*) FROM `orders` WHERE `customers_street_address` != `delivery_street_address`
gives: 674
or 23.88%

SELECT count(*) FROM `orders` WHERE `customers_street_address` != `billing_street_address`
gives: 273
or 9.67%

 

Site #3, typical osCommerce shop ... number of orders = 21901;

 

SELECT count(*) FROM `orders` WHERE `customers_street_address` != `delivery_street_address`

gives: 674
or 3.07%

SELECT count(*) FROM `orders` WHERE `customers_street_address` != `billing_street_address`
gives: 0 (Zero)
or 0%

 

Site #4, a softcore "adult" shop ... number of orders = 19906;

 

SELECT count(*) FROM `orders` WHERE `customers_street_address` != `delivery_street_address`

gives: 2343
or 11.77%

SELECT count(*) FROM `orders` WHERE `customers_street_address` != `billing_street_address`
gives: 1098
or 5.51%

 

 

I'll do a few more tomorrow...

[ArtcoInc]

I have not seen a program (storefront or accounting) that addresses addresses (no pun intended) as I would like to see them ...

 

Let's say that I have a customer named Burt. Burt works at the university, but also works out of his own studio. In osC, we can set this up either as two different customers, or one customer with two different billing/shipping addresses.

 

Burt may call me from his studio asking for a product that he bought from me for the university. I need to be able to look this up, and to distinguish one from the other.

 

One day, Burt leaves the university, and Carine takes over for him. Most businesses will just change Burt's name to Carine in their system (won't her email address probably change too?). But, if we had Burt as one account (with two shipping addresses), we have a problem.

 

So, let's say that we had two different accounts for Burt, and we just changed his name to Carine in the university account. Now, let's say that Burt gets a job at a different school, and calls asking for me to look up the product he used to buy when he was at the first university. I now have to remember what the new person's name associated with the old university has changed to.

 

I have history for three different address for Burt, although only two are still active. Likewise, I have two different people (Burt and Carine) linked to the same address (at the first university), although only one is still active. I want to be able to maintain the sales history independently for each person and each address.

 

So, for me, there is a one-to-many relationship with the 'person' and an 'address'. And, I want to be able to set a flag saying which relationships are active, and which aren't.

 

I see the same issues with phone numbers. Should they linked to the person, or the address? I can see how one phone number is linked to a person (their cell number), while another phone number is linked to the address (the landline into the university).

 

And, I don't even want to mention what happens when a person changes their email address ....

 

Malcolm

[♥bruyndoncx]

@@burt different shipping address based on orders are a little less. About 9.5% in my case.

[burt]

I have two options in front of me, for a redesign of the checkout flow;

 

#1.  remove the main address entirely....customers can now set up an account with;

• name
• surname
• email

Important note:  we already have the capability to *not* ask for an password.  The checkout (as it presently stands) works perfect without it.

 

Intangible product (eg a download);

• no further data required
• shipping skipped
• choose payment method

Checkout continues as normal.

 

Tangible product (eg, a blue widget);

• customer inserts shipping address
• choose shipping method
• customers inserts invoice address
• choose payment method

Checkout continues as normal.

 

Downside:

Needs a ground up rewrite of the checkout procedure pretty much, and bit of a rewrite of some other areas (eg some things in the account).

 

Upside:  

Very easy to create an account.

 

 

#2.  Rework the existing structure, but stay close to what osc already has

• change create_account.php to billing_details.php (or some such name).

  remove password fields and checking

  remove as much of the unwanted questions as possible (gender, dob and so on)

• extra db to split out max_addresses:   shipping_max_address = 1, billing_max_addresses = 0
• rework (a bit) checkout_shipping and checkout_payment to look at max_addresses for each and give options or not to change

At this point the "main address" (what used to be the create_account) page is good for both shipping and billing, but they can change shipping address if they want...good for the vast majority of shops.

• checkout continues as normal

Downside:

Thoughts?

 

Upside:

Minimal code changes

 

 

In both cases, it would be very very easy to write a checkout_success module asking the shopper if they wish to save their details (become an account holder) or not (remain a guest)..

[♥bruyndoncx]

@@ArtcoInc

In our accounting system (osFinancials/Turbocash) we have a customer entity for the business (or private account)

and optional contacts for each business contact.

If you really want to find model based upon best practices,

I think you should try to find out how a CRM (customer relationship management)

systems do this.

Opensourece wise I think you might be able to learn from sugarCRM / Vtiger or perhaps Salesforce.

If i go digg in my notes from previous IT jobs, I might find some database schema from siebel, oraclecrm, vantive, peoplesoft, sap just to name a few ...

[burt]

For #1, the flow goes;

 

1. add to shopping_cart
2. press checkout
3. fill in very minimal details
   => name, email
   => account is created but with no addresses
   => hence no way for shop to work out correct VAT prior to checkout
4. checkout_shipping
   => MUST add in a shipping address => choose shipping method
5. checkout_payment
   => MUST add in a billing address (maybe a tickbox to say use same as shipping) => choose payment method
6. PAY
7. checkout_success
   => choose to keep account, or nuke account

For #2, the flow goes;

1. add to shopping_cart
2. press checkout
3. fill in minimal details on "new" billing_details (aka create_account)
   => name, email, address
   => account is created
4. checkout_shipping
   => choose to add in a different shipping address
   => choose shipping method
5. checkout_payment
   => uses address set up in point 3
   => choose payment method
6. PAY
7. checkout_success
   => choose to keep account, or nuke account

[♥bruyndoncx]

@@burt

#1 don't you need an address to decide what VAT to charge ?

 

#2, looks very similar to better checkout to me

[♥Moxamint]

 

For #1, the flow goes;

 

1. add to shopping_cart
2. press checkout
3. fill in very minimal details

   => name, email

   => account is created but with no addresses

   => hence no way for shop to work out correct VAT prior to checkout

4. checkout_shipping

   => MUST add in a shipping address => choose shipping method

5. checkout_payment

   => MUST add in a billing address (maybe a tickbox to say use same as shipping) => choose payment method

6. PAY
7. checkout_success

   => choose to keep account, or nuke account

 

@@burt #1 will work the best for my business and looks a lot more fluent.  I never thought a full address was necessary for the account creation.  The way the current osC changes the address book entry after the customer have edited their account information also seems silly to me.  So the name and e-mail will be maintained separately for account, billing, and shipping.  I achieved that buy creating a new page "checkout address" to just handle the billing and shipping addresses after customer login or account creation with minimal details.  The shipping and payment method selection pages do not deal with addresses anymore because it's all taken care of by the new "checkout address" page.  If the customer wants to change shipping or billing addresses, they go back to "checkout address" page.

 

The above checkout flow lacks the option for the customer to use multiple shipping or billing addresses.  I force them to have only one shipping address and one billing address only because I do not know how to let them choose from multiple addresses without breaking the checkout flow.  When they need to ship to somewhere else or to bill to someone else, they just need to edit their existing address entries in the "checkout address" page.

 

Thanks, Eddy

 

P.S. Since the info required from the customer are very minimal during account creation, maybe account creation and login can fit into the same page and thus eliminating the whole create account page?

[♥Moxamint]

To stay on topic, 99% of my customers have only one address IF they made the purchase by/for themselves.  For governmental purchases that make up one fourth of all online orders on my site, however, the billing and shipping addresses are almost always different.

[clustersolutions]

I don't think you meant that by multiple shipping addresses on a per order base???

 

Anyway, yes, on no account address. I have been doing that for many years now as asking for address during registration is very 1999. It is especially since I have implemented FB login, where you just don't get an account address. I believe my github osc copy has simple registration and the revised checkout logic...

 

I did revise the core to ask for the shipping address if a customer has no defined address first thing at checkout since checkout_shipping needs it. I still allow the customer to have multiple addresses and leaving customer- -> address in a one to many relationship. 

 

I think limiting customers to have a single address would make the software less robust. Well, for my B2B customers, the account registration actually requires it to be 1999...I recently had implemented a mobile ready location based store locator and the address book came in handy...it allows a vendor to define its physical locations and submit to the store locator...

 

Simplifying the registration should make the software more attractive to users...

 

 

I have recently been wondering about the ability in this software to have;

- account address
+ multiple shipping addresses
+ multiple invoicing addresses

[♥kymation]

I ran the SQL on one of my customers' store that is almost entirely b2b, and the number of customers with two or more addresses is about 24%.

 

Either of the options @@burt listed would work, and be an improvement over what we have now. I've created something  similar to #2, but with step 3 having a full address box and a second slide-out address box if the customer requests separate billing/shipping addresses. It seems to work well for the b2b crowd, but is probably overkill for a consumer site. It might be good to have a bare-minimum checkout for the consumer sites, but include hooks to add in the extra information for b2b sites.

 

Regards

Jim

[♥Tsimi]

I have no stats regarding my customers but "I" as a customer always have at least 2 addresses. One home and one company depending on the products I order some I want to have shipped to the company some directly home. (No, no nasty products. ;)  ) I never pay really attention to the billing address but I guess that would be my home address.

[burt]

http://seen-online.co.uk/checkout/login.php

 

PLEASE USE A REAL EMAIL ADDRESS THAT YOU HAVE ACCESS TO.

So that you can test the new system for "welcome" and "order process" emails.

 

If you are thinking of using asdf@@asdf.com or somesuch, please don't bother testing as you waste your time and mine.

 

Don't get hung up on the address auto-completer, that is highly experimental code.  

Sometimes works good, sometimes not.

 

I have 1 known problem to solve, which you might or might not notice.

[piernas]

I've received the confirmation email twice, with two different keys but same order number. Maybe it sends it before and after creating the account?

 

Also, if you mark the option for creating the account and in the password screen you decide not to create it, the back button doesn't take you to the previous page but to account details.

[♥John W]

I know you said not to focus on this, but  the address auto completer is one of the best, coolest, greatest things I've seen on this forum in a long time and my address came up quickly.  But, it didn't add my zip or country into the fields.  I'm guessing this is some Google magic vodoo.

 

I like this checkout a lot and you have some great ideas here.  It worked very well.

[burt]

Thank You for testing Chaps.  I already made come changes based on the feedback...will post more later.

 

But, it didn't add my zip or country into the fields. 

 

It is a strange beast.  For all the other countries I have tried, it works well.  

For US addresses it bombs on Zip and Country.

 

Edit:

I *think* I solved it.  Looks like it requires the State Input Box to be active.

Could you try again ?  No need to create an account..

[♥John W]

I just used the google maps auto address and it doesn't show my zip or country in it, so I wonder if that's part of it.  On your checkout it showed my zip and country but just didn't add it.  Anyway I look at it, this is a great set of ideas you're working on. 

[burt]

I *think* I solved it.  Looks like it requires the State Input Box to be active.

Could you try again ?  No need to create an account..