Website wait times for delivery change

[schonelucht]

Yes, I misspoke. I am comparing rate of incoming orders to the production. The fact that wait time grew, means that the incoming orders grew faster than the production.

You keep saying like that's a definitive. Maybe in your mind, but you haven't answered my doubts for now. I think they kept in a remarkable lockstep.

(average does not work, must be weighted average)

My graph is of course weighted according to geographical distribution (55% 35% 10%) I am actually debating changing the coefficients because it seems China has become a relatively stronger market compared to Europe than last year.

 

[schonelucht]

To get rid of the week rounding business, all wait times shown in days.

This is absolutely unsound because Tesla does not specify the delivery period with that precision. When your input is rounded, your output must necessarily be so too if you want to draw correct conclusions otherwise you risk creating signal while there is none in the underlying data. See Significant figures - Wikipedia, the free encyclopedia for a starting point of an in depth discussion on this issue.

 

[schonelucht]

View attachment 177696

This graph shows the flaws in your methodology really well. For example on Jan 20th, wait time for Europe was March across all models. That's at most 60 days while your graph shows 80 for that time frame.

The reality is than when Tesla posts a date, they intend to keep that date till the end of the period. For example, if Jan 1st they post a date for March and on Feb 1st they change it to June that does not mean that an order half way January gets delivered in May. It will still be delivered in March. You need therefore to account for the end of the period, not the start of the period like you do. Now ordinarily it wouldn't matter for the trend line (everything gets shifted up and down by some relatively fixed period) But Tesla changed the way they batch geographical deliveries between 2015 and 2016. The much heavier batching and subsequent larger step values in delivery dates make it so that your method biases towards erasing the dips in waiting times in 2016 compared to 2015. No wonder the trend line goes up.

 

[vgrinshpun]

Hey, Schonelucht, why don't you wait until I have a chance to post the reconciliation of our methodologies before using judgmental language ("flaws in your methodology").

I reserved this courtesy for you and expect the same in return.

 

[schonelucht]

Hey, Schonelucht, why don't you wait until I have a chance to post the reconciliation of our methodologies before using judgmental language ("flaws in your methodology").

Apologies. Hopefully you'll refrain then from claiming that my method misrepresents the true trendline before we got everything sorted?

I reserved this courtesy for you and expect the same in return.

Respectfully, that was not how it was looking to me for the last few days.

 

[vgrinshpun]

Respectfully, that was not how it was looking to me for the last few days.

I reported what I saw based on my analysis. At no time I had declared methodology that you used "flawed", just assumed that there were some differences between the approaches we used, and asked you to list your assumptions.

 

[vgrinshpun]

Apologies. Hopefully you'll refrain then from claiming that my method misrepresents the true trendline before we got everything sorted

I have never claimed that your method misrepresents the trend lines, and never claimed that my trend lines are "true" and yours are not.

What I reported is that according to my analysis (assumptions for which I clearly described) the trend lines are going up, not down, contrary to the common belief held before.

In the same post I mentioned that I will do comparison of the methods we used, but only after I have a chance to do the graph for Asia/Pacific region, because otherwise the comparison will not be based on complete data set.

 

[schonelucht]

I have never claimed that your method misrepresents the trend lines, and never claimed that my trend lines are "true" and yours are not.

Come on, now :

As I mentioned before, I do not believe that Schonelucht's graphs are accurate. I actually reviewed all the data that I accumulated for NA wait times and result, as I suspected, is actually the opposite of the one's in Schonelucht's graphs. The trend line for the NA wait time is UP, not down.

You ask me a few questions about my data, ignore my response ('not enough time') completely and then link to your own post with the questions from various other threads to support your message that my graphs are inaccurate.

 

[vgrinshpun]

I have never claimed that your method misrepresents the trend lines, and never claimed that my trend lines are "true" and yours are not.

Come on, now :

As I mentioned before, I do not believe that Schonelucht's graphs are accurate. I actually reviewed all the data that I accumulated for NA wait times and result, as I suspected, is actually the opposite of the one's in Schonelucht's graphs. The trend line for the NA wait time is UP, not down.

You ask me a few questions about my data, ignore my response ('not enough time') completely and then link to your own post with the questions from various other threads to support your message that my graphs are inaccurate.

I hope you appreciate the difference between stating a position, without masking the fact that it is contradictory to a competing position, while NOT being judgmental about it vs. stating position by puting down the method that the competing position was arrived at.

I used the former approach: " I do not believe that Schonelucht's graphs are accurate"

While you indulged in the latter one: "This is absolutely unsound because...", "This graph shows the flaws in your methodology really well."

If you do not recognize the difference, I may have wasted my time going over my posts making sure that there is no offensive judgmental words there and substituting them with words emphasizing that I am just expressing my opinion, and instead, going forward, just adopt the language you've used, pounding in how your method is "absolutely unsound" and how your own graph "shows the flaws in your methodology really well".

Now, that I am over with venting my frustration, the essence of the reason I believe your graphs produce inaccurate result is in you not using one of the assumptions I listed up thread, the one that I also discussed a long time ago in this thread (perhaps a year ago - need to dig out the reference): that the wait time is accurate only on the day the update was made.

The underlying thinking is that on the day Tesla updates the projected delivery time, it allocates a delivery window within which orders are projected to be delivered. With the passage of time incoming orders fill in the allocated window, starting with the first day within this window and going on until the next time the estimated delivery time is updated. At that time a new window is given for deliveries.

Using example you used , as shown on the attached graph, my approach is illustrated by orange line. It shows wait time in the beginning of the period, on November 11, 2015 as 96 day or 13.7 weeks (difference between November 11 and delivery projection of March 1st, 2016). At the time of the next update, on January 30, 2016 the wait time was 91 days or 13 weeks (difference between January 30 and delivery projection of April 30 - there is a typo in my underlying data series as this should have been April 16 as in late April. I do not have time to re-do the annotated graph, so this typo is not fixed. I will fix it next time on the updated graphs tomorrow. This does not change the essence of the example). The orange line that represents the trend in waiting time between these two points in time (November 26th and January 30th) then connects the above points on the graph.

Your approach, on another hand (disclaimer: since you did not provide the data series underlying your graph, I scaled all data off it, so there is possibility for small scaling errors), as annotated in green on the attached graph, essentially results in the assumption that after November 26th there were very few incoming orders and delivery date of March, given on November 26th, 2015 was kept the same all the way until January 30, 2016, with the corresponding "fictitious" wait time reduced to 6 weeks, and then jumping up along the vertical line when delivery time was updated on January 30th to Late April, as if that was a day when huge batch of orders was received and the wait time jumped from 6 to 15 weeks. This is why I believe that your approach does not result in the accurate trending of the wait times.

 

[dennis]

Problem is that capacity is about to increase 50% very soon. The demand would have to increase much faster than trend if Tesla is to fill this new production capacity pretty much instantly (if they want to meet the yearly guidance).

Production capacity for Model S in not about to increase 50% very soon, it is the combined production capacity for S and X. The wait time chart showing a small trend line increase is just for Model S. Demand for Model X is still unknowable because of the production issues and extremely limited wait time data.

 

[schonelucht]

The underlying thinking is that on the day Tesla updates the projected delivery time, it allocates a delivery window within which orders are projected to be delivered. With the passage of time incoming orders fill in the allocated window, starting with the first day within this window and going on until the next time the estimated delivery time is updated. At that time a new window is given for deliveries.

...

Your approach, on another hand (disclaimer: since you did not provide the data series underlying your graph, I scaled all data off it, so there is possibility for small scaling errors), as annotated in green on the attached graph, essentially results in the assumption that after November 26th there were very few incoming orders and delivery date of March, given on November 26th, 2015 was kept the same all the way until January 30, 2016, with the corresponding "fictitious" wait time reduced to 6 weeks, and then jumping up along the vertical line when delivery time was updated on January 30th to Late April, as if that was a day when huge batch of orders was received and the wait time jumped from 6 to 15 weeks. This is why I believe that your approach does not result in the accurate trending of the wait times.

Well, evidence from the delivery threads shows that is not the way Tesla actually allocates and fills windows. For example Werkelijke wachttijd - Model S ordered Dec 3rd, delivery Mar 17th. And here Werkelijke wachttijd - Model S is another one who ordered in Jan 13th and got delivered exactly the same day.

The reason is not, as you suggest, because there were no orders between those periods and then suddenly there was a huge influx which indeed would not be plausible. It's because Tesla batches up orders. So all the orders coming in late 2015/start 2016 for Europe were kept on hold and then produced all together beginning of January en all delivered begin of March. This does mean that indeed that those who ordered towards the start of production got a much shorter wait time. And that the first customer who ordered after that period got a sudden much longer delay because their order is held up before production/shipping. The example of the guy ordering halfway through January, delivered beginning of March shows clearly there is nothing fictitious about that 6 weeks delivery time.

Those additional dips are really necessary to take into account to get a good grasp on the wait times. And to be honest, even my graph doesn't do that completely since it's just a virtue of updating it at a higher sampling rate than yours instead of really sampling every single day. If I did the latter (a method the above evidence supports) I would get much stronger dips even than I do.

 

[Chickenlittle]

Interesting that delivery of model s ordered today June and model X July. Either still ramping up or higher demand model X than model s. I suspect extra QA probably still slowing relative delivery of model x

 

[Perfectlogic]

Production capacity for Model S in not about to increase 50% very soon, it is the combined production capacity for S and X. The wait time chart showing a small trend line increase is just for Model S. Demand for Model X is still unknowable because of the production issues and extremely limited wait time data.

I have written this several times already but I guess you haven't read my other posts. We do know the wait for the MX and even at a high production rate of 800 that backlog is just dissapointing compared to what it was before Tesla even revealed the car. Problem is that if demand trend continues for the MS, the MX needs to sell around 800/week to fill the remainder of the new 2k capacity. Those 10400 cars per month are almost as much as the total MX demand has been so far in the years leading up to the reveal and the 9 months after until now.

If Tesla gets the production capacity to 2k/week in a month as planned I think they will run through their backlog in less than 3 months leaving them short of sufficient demand to fill the 2k in Q4. I think even a 75k figure for the year would be quite dissapointing to the markets. The expectation all the way back to late 2014 was exiting 2015 at a 100k/year runrate, and Elon has talked about the X demand at least matching the S, even though I think he has toned it down lately. If they can't even meet 80k going into the year with a 10k+ backlog it is not great.

This along with the increased cash burn could be very burdensome on the stock in the next 12 months. On the other hand of course we have the positive of M3 demand being very strong, perhaps this hype could keep the stock afloat even if the other 2 points looks very grim, but I doubt it (in the short/medium term).

 

[Gerardf]

<snip> Problem is that if demand trend continues for the MS, the MX needs to sell around 800/week to fill the remainder of the new 2k capacity. Those 10400 cars per month are almost as much as the total MX demand has been so far in the years leading up to the reveal and the 9 months after until now. <snip>

You lost me there..

800 MX / week -->> 10400 per month ?
And 10400 MX is as much as total MX demand so far ?

Or do you mean 10400 MS + MX ?
12month x 10400 is 125k / year. Maybe in 2017, but not forecasted for 2016.

I assume some typo in there
Edit: @schonelucht: Thanks for explaining / correcting..

Also, how do you know the MX demand until now ? IIRC there were 25k to 30k reservations. That was the demand until final reveal.
Nobody can know how many actually delivered cars that will translate to until Tesla has produced enough demo units for all those that want to see the car before final configuration. Same for new orders, it will take about a year until we might have some well founded idea of real MX demand , at the very least until Tesla has a Model-X in every showroom and MX production humming.


BTW 75k cars delivered is still a very healthy 50% growth. Pretty impressive.
So would 400k delivered cars in 2018 be, instead of 500k aimed for. This shareholder would not complain in both cases.

 

[schonelucht]

You lost me there..

800 MX / week -->> 10400 per month ?

800 cars/week * 13 weeks/quarter = 10400 cars per quarter not month. Probably a typo by PerfectLogic. I think we all can agree that we'd like to see volume Model X deliveries to Europe and (especially) Asia happen sooner rather than later. Apparently US customers are remaining a little longer on the fence for converting a reservation into a firm order : while the backlog was over 20k US orders it seems unlikely Tesla will deliver more than half by the time they project to deliver new orders. In a way that's good news too. With 10k fence sitters that should be easily convinced before the end of the year to go ahead with the purchase, Tesla would only need 5k orders/quarter (and that includes EU/Asia backlog) for the second half to fill all model X production slots (assuming 800/week)

One of the extra sources I am watching to see how this develops is the model X tracker and more specifically the ratio of new orders/deliveries per single week.[/QUOTE]

 

[Perfectlogic]

You lost me there..

800 MX / week -->> 10400 per month ?
And 10400 MX is as much as total MX demand so far ?

Or do you mean 10400 MS + MX ?
12month x 10400 is 125k / year. Maybe in 2017, but not forecasted for 2016.

I assume some typo in there (or did I miss some context ?)


Also, how do you know the MX demand until now ? IIRC there were 25k to 30k reservations. That was the demand until final reveal.
Nobody can know how many actually delivered cars that will translate to until Tesla has produced enough demo units for all those that want to see the car before final configuration. Same for new orders, it will take about a year until we know, at the very least until Tesla has a Model-X in every showroom and MX production humming.


BTW 75k cars delivered is still a very healthy 50% growth. Pretty impressive.
So would 400k delivered cars in 2018 be, instead of 500k aimed for. This shareholder would not complain in both cases.

I meant 10400 per quarter instead of per month. There were 25k reservations before the reveal yes. Now the wait is 4-8 weeks for US/China and 4 months for Europe. I assume (like with the S) their largest market is the US, so given a weighted average of 8 weeks and an optimistic production rate of 800/week that only translates to a 6400 backlog.

According to this article Model X Hitting Showrooms In January? The X hit the showrooms in Jan, not sure if this turned out to be true or not. It would make sense for the car to be there, it would be an easy way to stimulate demand it is not like the wait is huge for the car at this point.

BTW 75k cars delivered is still a very healthy 50% growth. Pretty impressive.

While 75k would mean 50% growth, it would also be proof of the demand growth slowing quickly for the S and the demand for the X being very soft.

Kinda funny how you try spin a 75k to be positive, if you go back and look at the hype on this forum for the X last year then this is a huge letdown. I'm sure I could go back and find some hyper bullish posts on the X from you too. It is okay to be dissapointed with something, you don't have to try to twist everything to be positive just because you own the stock.

 

[Gerardf]

I meant 10400 per quarter instead of per month.

< snip>

While 75k would mean 50% growth, it would also be proof of the demand growth slowing quickly for the S and the demand for the X being very soft.

Kinda funny how you try spin a 75k to be positive, if you go back and look at the hype on this forum for the X last year then this is a huge letdown. I'm sure I could go back and find some hyper bullish posts on the X from you too. It is okay to be dissapointed with something, you don't have to try to twist everything to be positive just because you own the stock.

Yes, thanks. Schonelucht already explained that it had to be a typo.

On the 75k. : Well, as a shareholder I do my own number crunching, and I would indeed be fine with 75k deliveries in 2016. And no, I did not publicly mention significantly high Model-X expectations.

My judgement of Mr. Musk's personality is that he is not that much interested in short term and what wall-street thinks. I am sure you remember when he even made a comment that SP was at some point a bit on the high side. I DO think he is not into sandbagging, but consciously sets extremely ambitious goals, virtually impossible to achieve, to reach a final result that might be lower than that, but can be regarded a phenomenal achievement anyway. Like doing 400k in 2018 would be.
Each has to do their own number crunching and judgement on this. . I respect you in case you might see it very differently.

Edit / added :
You stated : " It is okay to be dissapointed with something, you don't have to try to twist everything to be positive just because you own the stock"

Umm, no. You misjudged me here.

 

[Gerasimental]

75k would be positive because Tesla's stated intention is to grow by 50% yoy and not to meet or exceed the expectations of hyperbulls on TMC.

 

[Perfectlogic]

75k would be positive because Tesla's stated intention is to grow by 50% yoy and not to meet or exceed the expectations of hyperbulls on TMC.

No, Tesla's specific guidance is 80-90k for the year. Which you could even argue is down from a higher implied guidance when they were talking about exiting 2015 at a 100k/year runrate earlier.

 

[vgrinshpun]

Well, evidence from the delivery threads shows that is not the way Tesla actually allocates and fills windows. For example Werkelijke wachttijd - Model S ordered Dec 3rd, delivery Mar 17th. And here Werkelijke wachttijd - Model S is another one who ordered in Jan 13th and got delivered exactly the same day.

First of all data points that are picked up from the delivery monitoring thread after the fact is not an evidence of how Tesla operates in general, just an evidence how it operated for these two data points. As I am sure you are aware Tesla had some quarters that it operated in a way that maximized deliveries of cars produced within the quarter, which indeed included batching that you've described, but during other quarters, there was no batching and orders were uniformly filled in as they came.

Additionally, Tesla certainly did not operated like that during all of the period between the updates, i.e. November 11th through January 30th, just during portion of it, as accumulation of the orders was over before the end of this period on 01/30/16. (see data series below for illustration)

And finally, even when Tesla operates in batching mode, it does not apply to some periods because they fall within the time when Tesla allocates production to the specific region, so there is no accumulation of orders within these periods for this specific region.

So this is, I believe, is one of the problems with your method.

Another one is the fact that you assume that there is information on deducing what waiting time is between the days when projected delivery was updated. You assign a two week period as the end of the delivery window, and then keep that date fixed as time passes after the day of the projected delivery, which in effect shortens wait time as we move in time from one date of the update to the next one.

The problem is that this is a conjecture, and not a real data point. That is why in my method I assume that we do not know what wait time was between the dates the projected delivery was updated, I only consider data points that we have concrete information about - Projected Delivery on the Date of Update only. Than we can draw a trend line between the two consecutive points corresponding to the Dates of Update only. The overall trend line can be added on top of that, for longer periods that include multiple data points for several Dates of Update.

Take the period that we discussing. It starts with the Projected delivery of March on November 11th, and goes on till the next Date of Update on January 30th, with projected delivery date Late april. By assigning two week period as a window for delivery, you are saying that cars entered in production queue after November 11th are delivered by the middle of March, and then, cars entering production queue on and after the date of the next update, January 30th are delivered in the second half of April ("late April"). The problem that this approach results in modeling that assumes that no cars were delivered in Europe in second half of March and first half of April, which is inaccurate.

To contrast this with my method, it is based on assumption that we have knowledge about the delivery estimate only at two dates corresponding to the dates of update: that on November 11th projected delivery was March 1st ("March"), and on Janaury 30th projected delivery was April 16th ("end of April"). Those are the only points with known data, and they are connected by the trend line.

The example of the guy ordering halfway through January, delivered beginning of March shows clearly there is nothing fictitious about that 6 weeks delivery time.

Of course it is not. The 6 week delivery is absolutely certainly IS fictitious.

First, the example you are referring to - of a guy ordering on January 13th and receiving on March 17th - had 9+ weeks of wait time, not the fictitious 6 weeks.

Second, as you are well aware the in transit/European assembly time is 6 weeks (and you recently even indicated that it is now more like 8 weeks), so how a TOTAL wait time for European deliveries can be 6 weeks? It is fictitious wait time indeed.

So, in conclusion, because your method assumes that we know what the wait time between the Dates of Update is, it produces inaccurate results, as shown in examples laid out above.

That is why in my method, I assume that we have only discreet data points, indicating estimated delivery on the Dates of Update only,
and, once again, it is based on the following assumptions:

• The wait time is accurate only on the day the update was made
• Reference to a month means the 1st of the month (June means June 1)
• Reference to a "late" month means 16th of the month (Late June means June 16)