tedpower
Joined 14 years ago
Joined 14 years ago
So the way that Bend works, we take a transaction, and then match it with the best available 'emissions factor'. So, for example, if you purchase something at Starbucks, we match that transaction to the Starbucks specific emissions factor: https://bend.green/starbucks
Over 65% of total market cap is now covered by this sustainability data, and we aggregate that data, and use it to estimate the emissions for each transaction.
Of course there is a very long tail. So if you buy a coffee at a small coffee shop, we likely don't have that merchant-specific data. In those cases, we fall back to "Merchant Category Code" (MCC) emissions factors.
And finally, in some cases we have SKU-level data. E.g. we have an Amazon Business integration where we get the actual specific item data.
Long story short is we have surprisingly high merchant coverage — well north of 60%. We have pretty limited SKU-level coverage today, but expanding. And then we always have an MCC fallback. The larger the merchant, the more likely we are to have good data for them (we're trying to grow coverage for mid market and smaller businesses with Bend).
This means that you can get a pretty detailed, totally automated sense of your emissions hotspots.
More info here: https://usebend.com/how-it-works
Setting the GHGP aside, my own personal opinion about how we interpret GHGP data is that it's important to make a clear distinction between upstream emissions and downstream emissions. For example, 'use of sold products' (Category 11) is also not something you can determine from spend data. But I'd argue that 'use of sold products' is a very different thing than upstream emissions (even though they're all lumped under Scope 3).
Commuting is a less clear-cut case, but I think of commuting (that is paid for by employees) as more of a downstream emissions category.
We wrote up some notes on this here: https://bend.green/faq/downstream-emissions
As startups, you have an unfair advantage — it’s much easier to build good carbon habits early, vs. retooling your business after having already invested large amounts of capital in carbon-intensive practices and depreciating assets.
We do offer enterprise pricing for API access for larger customers.
Re: do you have any concerns that your users might shortcut the work to produce high quality estimates of their Scope 3 emissions when you have made it so easy to get lower quality estimates?
> I think the high order bit here is that 99%+ of companies don't measure their emissions at all. This is for a good reason — measuring your emissions historically has been quite labor-intensive. Even for large companies, there is always a 'long tail' of 'Scope 3 goods and services' transactions that are hard to measure. Our goal is to create a scalable solution so that a much larger share of companies are able to participate.
Re: your grocery store example —
> This is a fair point. Our main belief is that realtime, actionable data trumps perfectly attributed data, if perfectly attributed data requires a bottoms-up manual model. The advantage of the spend-based approach is that (1) it's realtime, and (2) it aligns incentives at the company level. The holy grail, however, would be itemized spend data (level 3 data), where you could factor in the emissions of your specific line-items. Unfortunately, that data is nearly impossible to get (yet). Maybe that's Bend 2.0 :)
Re: re-accounting historical emissions —
> Yes! We use the emissions 'factor' that most closely matches the transaction date. So for example, if you bought a Starbucks coffee in 2020, we would use the 2020 Starbucks factor, and if you bought a Starbucks in 2021, we would use the 2021 Starbucks factor. If Starbucks is late to publish their 2022 report, we would recalculate the emissions when the info is updated. For our category fallbacks, we also take currency / region into consideration.
Happy to chat more, either with you or the WRI folks! Thanks for the questions.