What is usage-based billing?

Explaining the new billing paradigm and what it means for you

When you’re thirsty, you might go over to a faucet and turn on the water, which your house’s water meter conveniently tracks. At the end of the month, the water company bills based on the usage data from your water meter. The process is frictionless, and it makes sense–for the consumer and the water company.

This convenience gets to the heart of usage-based billing: pricing and payments based upon communicating usage data instead of a fixed price in dollars and cents. Until recently, most SaaS businesses didn’t have access to the metering tools required to implement usage-based monetization–even when customers prefered it.

Think about it through the lens of an Uber or Lyft customer. When passengers ride in their drivers’ cars to their destination, the ride-sharing apps conveniently track the distance and duration of their trips. Now, customers expect the same convenience from SaaS.

“Firms are shifting from one-time perpetual sales or fixed monthly subscriptions to consumption models that blend one time, subscription, and usage-based billing.” – Forrester Wave

The industry’s shift toward usage-based billing may even eclipse the decade-long move toward fixed subscriptions. It isn’t all sunshine and roses, however, as you consider the difficulties SaaS companies face in responding to this new trend in customer demand.

Challenges of usage-based billing

For one, you can’t just install an equivalent “water meter” in every business. Building a usage-based billing system requires time and money, and often involves revaluating how and where your company provides value.

In SaaS, for example, it can take a developer weeks or months to build a way to track usage data and bill for it. I would know–my team and I did that for more than 25 revenue-generating companies at Sproutbox. That was time our business wasn’t able to focus on building our core products, and it resulted in delays getting to market. Even worse, anytime we wanted to change pricing, developers would have to spend hours in our pricing meetings.

Perks of usage-based billing

A usage-based billing platform isolates pricing from your code base and empowers you to flexibility change pricing. Executives and marketing leaders can customize and test pricing in real-time without burdening development teams or waiting on releases.

Building a billing system centered around usage data is also significantly easier than traditional billing and payment systems. It’s simple–you just outline what items the development team needs to track, and the usage-based billing system does the rest. Pricing, payment processing, collections, customer communication, revenue optimization, and SaaS reporting all come out of the box.

Usage-based billing also allows businesses to help identify where they provide value and match variable costs with variable pricing. This can be a huge help to new companies, allowing them to let initial usage tracking data influence pricing decisions from day one.

Consumers and billing

Saving time, saving money, and adding flexibility to your pricing is great, but above all, one of the biggest benefits of making the switch to usage-based billing is that customers will love you for it. They are the ones driving this billing evolution because it means they get fair, transparent pricing that’s more aligned with the value they receive.

And that’s how billing should be.

About Cheddar

Billing built for developers. Using a unique usage-based approach to billing, we cut the time it takes to build monetization into a product by as much as 90%. No matter if your billing model is metered, one-time, subscription, or some combination, Cheddar allows you to focus on building awesome products, not billing for them. Sign-up for a free developer account.

What is usage-based billing? 2017-11-07T12:27:19+00:00

What is usage-based billing?

Usage-Based Billing

Explaining the new billing paradigm and what it means for you

When you’re thirsty, you might go over to a faucet and turn on the water, which your house’s water meter conveniently tracks. At the end of the month, the water company bills based on the usage data from your water meter. The process is frictionless, and it makes sense–for the consumer and the water company.

This convenience gets to the heart of usage-based billing: pricing and payments based upon communicating usage data instead of a fixed price in dollars and cents. Until recently, most SaaS businesses didn’t have access to the metering tools required to implement usage-based monetization–even when customers preferred it.

Think about it through the lens of an Uber or Lyft customer. When passengers ride in their drivers’ cars to their destination, the ride-sharing apps conveniently track the distance and duration of their trips. Now, customers expect the same convenience from SaaS.

“Firms are shifting from one-time perpetual sales or fixed monthly subscriptions to consumption models that blend one time, subscription, and usage-based billing.” – Forrester Wave

The industry’s shift toward usage-based billing may even eclipse the decade-long move toward fixed subscriptions. It isn’t all sunshine and roses, however, as you consider the difficulties SaaS companies face in responding to this new trend in customer demand.

Challenges of usage-based billing

For one, you can’t just install an equivalent “water meter” in every business. Building a usage-based billing system requires time and money, and often involves revaluating how and where your company provides value.

In SaaS, for example, it can take a developer weeks or months to build a way to track usage data and bill for it. I would know–my team and I did that for more than 25 revenue-generating companies at Sproutbox. That was time our business wasn’t able to focus on building our core products, and it resulted in delays getting to market. Even worse, anytime we wanted to change pricing, developers would have to spend hours in our pricing meetings.

Perks of usage-based billing

A usage-based billing platform isolates pricing from your code base and empowers you to flexibility change pricing. Executives and marketing leaders can customize and test pricing in real-time without burdening development teams or waiting on releases.

Building a billing system centered around usage data is also significantly easier than traditional billing and payment systems. It’s simple–you just outline what items the development team needs to track, and the usage-based billing system does the rest. Pricing, payment processing, collections, customer communication, revenue optimization, and SaaS reporting all come out of the box.

Usage-based billing also allows businesses to help identify where they provide value and match variable costs with variable pricing. This can be a huge help to new companies, allowing them to let initial usage tracking data influence pricing decisions from day one.

Consumers and billing

Saving time, saving money, and adding flexibility to your pricing is great, but above all, one of the biggest benefits of making the switch to usage-based billing is that customers will love you for it. They are the ones driving this billing evolution because it means they get fair, transparent pricing that’s more aligned with the value they receive.

And that’s how billing should be.

About Cheddar

Billing built for developers. Using a unique usage-based approach to billing, we cut the time it takes to build monetization into a product by as much as 90%. No matter if your billing model is metered, one-time, subscription, or some combination, Cheddar allows you to focus on building awesome products, not billing for them. Sign-up for a free developer account.

What is usage-based billing? 2018-02-08T05:09:09+00:00

Cheddar’s funding and what it means for Bloomington

Trends in Midwest Tech 

Below is a brief guest column Mike Trotzke, CEO of Cheddar, wrote for Bloomington’s local newspaper, The Herald Times.

From limestone quarries and furniture factories to Indiana University and Cook Group, Bloomington’s economy has had a variety of drivers over the years. Now, we see hints of what may shape Bloomington’s next phase of economic success– and it comes from technology companies.

Our billing software company, Cheddar, recently raised $1.25 million from investors to launch into high-growth mode. You might say, “Big deal — that’s just one, small company.” But, Cheddar’s success isn’t isolated. The financing is a result of two trends shaping our economic landscape– budding technology startups here in Bloomington and an increasing number of Midwestern investors with the experience to support them.

Over the last decade, Bloomington has quietly built 20–30 small, high-growth companies, many similar in potential to Cheddar. Technology startups like Periodic, Mavenly, or Bee Corp have remained low in headcount, focusing their attention on refining products to be sold all over the world. Unlike typical service or manufacturing businesses that might steadily grow over the course of their lifetime, technology startups tend to mature at rates relative to their funding. Online software, once dialed in, becomes significantly easier to scale than physical goods or services.

The second trend shaping Bloomington is the rise of Midwest venture capital funds wanting to invest in high-growth companies. Just five years ago, Cheddar would have had to take a long shot in places like San Francisco with investors that had little incentive to invest outside of their area. Now, Bloomington companies can drive to Chicago, Cincinnati, St. Louis and other Midwestern cities to secure investment from firms like M25 Group and Connetic Ventures.

Combined, these two trends catalyze economic opportunity. Indianapolis is a prime example of an economy invigorated by startups and investors. Over the last few years, Indy’s technology sector has brought money into its city, created thousands of technology jobs at triple the rate of the national average, and propelled the capital forward. It’s easy to see the shift driving through downtown Indianapolis– their tallest building was recently renamed to “Salesforce Tower” to represent one of the city’s largest technology companies. Salesforce now employs over 1,000 people with plans to add 800 more over the next few years.

Cheddar’s funding could mark a turning point towards similar economic diversity here in Bloomington, but it will take support from the community. We should not try to be Silicon Valley or Indianapolis, but Bloomington should leverage these trends to enhance our unique, creative culture, strengthen our nonprofits and grow local business. The investment in Cheddar was one of the first times that a local technology company received funding from venture capitalists outside of our state, and that means a lot more than just cash flowing into Cheddar. Outside investors will visit the city to monitor companies, ask about other investment opportunities, and begin to invest in more of our startups.

Cheddar has high aspirations. It may or may not reach its full potential. Regardless, investing in high-growth Bloomington companies means investing in the future of Bloomington’s economy, jobs, and community, making our city more sustainable and ensuring it continues to be a great place to work, play, and raise families.

That’s good for all of us.

Mike Trotzke is CEO at Cheddar and a Cofounder of SproutBox.

Cheddar’s funding and what it means for Bloomington 2018-02-08T05:16:14+00:00

Cheddar’s funding and what it means for Bloomington

Below is a brief guest column Mike Trotzke, CEO of Cheddar, wrote for our local newspaper, The Herald Times. I thought you might be interested in checking it out.

From limestone quarries and furniture factories to Indiana University and Cook Group, Bloomington’s economy has had a variety of drivers over the years. Now, we see hints of what may shape Bloomington’s next phase of economic success– and it comes from technology companies.

Our billing software company, Cheddar, recently raised $1.25 million from investors to launch into high-growth mode. You might say, “Big deal — that’s just one, small company.” But, Cheddar’s success isn’t isolated. The financing is a result of two trends shaping our economic landscape– budding technology startups here in Bloomington and an increasing number of Midwestern investors with the experience to support them.

Over the last decade, Bloomington has quietly built 20–30 small, high-growth companies, many similar in potential to Cheddar. Technology startups like Periodic, Mavenly, or Bee Corp have remained low in headcount, focusing their attention on refining products to be sold all over the world. Unlike typical service or manufacturing businesses that might steadily grow over the course of their lifetime, technology startups tend to mature at rates relative to their funding. Online software, once dialed in, becomes significantly easier to scale than physical goods or services.

The second trend shaping Bloomington is the rise of Midwest venture capital funds wanting to invest in high-growth companies. Just five years ago, Cheddar would have had to take a long shot in places like San Francisco with investors that had little incentive to invest outside of their area. Now, Bloomington companies can drive to Chicago, Cincinnati, St. Louis and other Midwestern cities to secure investment from firms like M25 Group and Connetic Ventures.

Combined, these two trends catalyze economic opportunity. Indianapolis is a prime example of an economy invigorated by startups and investors. Over the last few years, Indy’s technology sector has brought money into its city, created thousands of technology jobs at triple the rate of the national average, and propelled the capital forward. It’s easy to see the shift driving through downtown Indianapolis– their tallest building was recently renamed to “Salesforce Tower” to represent one of the city’s largest technology companies. Salesforce now employs over 1,000 people with plans to add 800 more over the next few years.

Cheddar’s funding could mark a turning point towards similar economic diversity here in Bloomington, but it will take support from the community. We should not try to be Silicon Valley or Indianapolis, but Bloomington should leverage these trends to enhance our unique, creative culture, strengthen our nonprofits and grow local business. The investment in Cheddar was one of the first times that a local technology company received funding from venture capitalists outside of our state, and that means a lot more than just cash flowing into Cheddar. Outside investors will visit the city to monitor companies, ask about other investment opportunities, and begin to invest in more of our startups.

Cheddar has high aspirations. It may or may not reach its full potential. Regardless, investing in high-growth Bloomington companies means investing in the future of Bloomington’s economy, jobs, and community, making our city more sustainable and ensuring it continues to be a great place to work, play, and raise families.

That’s good for all of us.

Mike Trotzke is CEO at Cheddar and a Cofounder of SproutBox.

Cheddar’s funding and what it means for Bloomington 2017-10-03T15:00:18+00:00

Cheddar Sans Getter

Hey Cheddar friends, fans, and customers – You may have noticed we have a new domain name, GetCheddar.com! Most everyone refers to us as just ‘Cheddar’ already, so we decided to remove the ‘getter’ and make it official with a new domain name. We’re still the same fast, reliable, and featureful billing API you’ve grown to know and love with a simpler, sleeker name.

What Does This Mean for You?

Really, nothing. We’ll continue to support our cheddargetter.com API endpoints for quite some time. If you’re a current customer, this means that you don’t need to make any changes to your integration with Cheddar. If you have a Cheddar product account in development and are working on an integration, you should go ahead and use the cheddargetter.com endpoints.

If we decide to deprecate cheddargetter.com endpoints, we’ll give you plenty of advanced warning, so you can make the necessary changes to your integration, but it’s not something you’ll need to worry about in the near future.

Although we’ve set up redirects so you’ll never be lost, here’s where to find all of your favorite Cheddar resources going forward:

If you have any questions or feedback about the new domain, get in touch with our team via the Cheddar support forum.

Cheddar Sans Getter 2017-08-18T13:27:46+00:00

Scheduled Maintenance June 2017

Update 6-29-17: Maintenance Window Rescheduled for June 29th and June 30th

We’ve confirmed the new dates and times for our hosting environment migration. Here are the details for the rescheduled maintenance windows:

First Maintenance Window

Begins on Thursday, June 29th at 11:00 pm and ends at 3:00 am EDT (8:00 pm to 12:00 am PDT/3:00 am to 7:00 am June 30th UTC).

Second Maintenance Window

Begins Friday, June 30th at 11:00 pm and ends at 3:00 am EDT (8:00 pm to 12:00 am PDT/3:00 am to 7:00 am July 1st UTC).

No downtime is anticipated for either of these maintenance windows, although it is possible you may experience short periods of degraded performance.

To complete the migration process, we’ll have one more maintenance event in the next few weeks. We’ll let you know as soon as that maintenance event has been scheduled. These upgrades will not require you to make any changes to your integration with Cheddar. They simply ensure we have the best infrastructure possible in place to continue facilitating fast and secure interactions with our platform.

Thanks for your patience as we sorted out the schedule with our hosting provider! We think the new hosting environment will be worth the wait. As always, if you have any questions or concerns, please don’t hesitate to contact our team via our support forum, Twitter, or Facebook.

Update 6-26-17: June 26th Maintenance Event will be Rescheduled

Due to unforeseen circumstances, our hosting provider has informed us that they are unable to perform our migration to the new hosting environment today. As a result, we will not have the maintenance event that was initially scheduled for tonight (June 26th) from 11:00 pm to 3:00 am EDT. Cheddar will continue to to operate normally this evening.

We should be able to reschedule the migration for later this week, but will need to to have an additional maintenance event to accommodate our hosting provider’s requirements. The new maintenance windows are tentatively scheduled to take place on Thursday, June 29th and Friday, June 30th, but we’ll post again when dates and times for the new maintenance windows have been confirmed.

No downtime is anticipated for either of these maintenance windows, although it is possible you may experience short periods of degraded performance.

Original Post 6-20-17:

Hey CheddarGetters – we’re making some updates to our hosting environment that will require us to have short maintenance window during the evening of Monday, June 26th.

As part of our commitment to providing a responsive and secure platform for our customers, we’re upgrading our hosting environment to the latest version of our provider’s architecture. The new generation of our environment will include features like an upgraded virtual firewall, better security reporting, and greater flexibility for our team to make responsive adjustments and deployments as needed.

To begin the process of migrating to the new environment, we’ll need to have a short maintenance window next week. Here are the details:

Maintenance Window Date and Time

The window will begin on Monday June 26th at 11:00 pm and end at 3:00 am June 27th EDT (8:00 pm on the 26th to 1:00 am on the 27th PDT/ 3:00 am to 7:00 am on the 27th UTC). See update on 06-29-17 above for current dates and times for the maintenance window.

We don’t anticipate any downtime during this window, but it’s possible that you may experience short periods of degraded performance.

To complete the migration process, we’ll have one more maintenance event in the next few weeks. We’ll let you know as soon as the second maintenance event has been scheduled. These upgrades will not require you to make any changes to your integration with Cheddar. They simply ensure we have the best infrastructure possible in place to continue facilitating fast and secure interactions with our platform.

We know billing is an essential part of your business, so rest assured that we’re working hard to make sure this migration has minimal to no impact on you and your customers. If you have any questions or concerns in the meantime, please don’t hesitate to contact our team via our support forum, Twitter, or Facebook.

Thanks for billing with Cheddar!

Scheduled Maintenance June 2017 2017-06-20T07:16:54+00:00

How we did it: Responsive Email Design

How we did it: Responsive Email Design

Next week, we’ll be launching a brand new set of default email templates for CheddarGetter. We learned a ton about coding and designing responsive and highly-deliverable emails through the process.

From the get-go, we had a few goals for the new templates in mind:

  • High Deliverability
    We didn’t want these transactional emails ending up in spam.
  • Responsive Design
    We wanted the new templates to look great on every device.
  • Ease of Customization
    We wanted our customers to be able to customize the templates while still maintaining responsiveness and deliverability.

A basic responsive structure

You’d think accomplishing these goals would be pretty straightforward. Unfortunately, coding emails is hard. We knew we wanted to create something mobile-first, but we weren’t quite sure what the best practices were or where to get started. THANK GOODNESS there are awesome resources out there. We really liked the mobile-first, single column approach we found here. Since notifications we send are transactional emails, not visually dynamic marketing emails, a single column structure works really well. It also makes editing the content a little less complicated.

According to FogCreek’s approach, our single column email should scale to fit smaller screens, but it shouldn’t get too wide to read in desktop clients. A max-width table does a pretty good job of restricting the email’s width in most email clients, but, as is often the case with emails, there are a few clients that don’t support this property: Apple Mail, Outlook, and Lotus Notes.

Apple Mail

While Apple Mail doesn’t support “max-width,” it is one of the few email clients that supports media queries. By creating a style tag in the head and inserting this media query,

@media only screen and (min-width: 541px) {
  .cheddar-content {
    width: 540px !important;
  }
}

we can restrict the .cheddar-content table to 540px wide if the window is greater than 541px wide.

Outlook and Lotus Notes

Neither Outlook nor Lotus Notes 8 support the “max-width” property. Luckily, these rogue clients are mostly used to view emails from desktop computers, so we don’t need to be as concerned with responsiveness here. A fixed-width table does the trick. We’re applying a few conditionals: (IE) covers Lotus Notes and earlier versions of Outlook, while (gte mso 9) covers Outlook 2007+. There’s also an identical conditional in the footer of the default notifications that contains all the close tags for this table.

<!--[if (gte mso 9)|(IE)]>
  <table width="540" align="center" cellpadding="0" cellspacing="0" border="0">
    <tr>
      <td>
<![endif]-->

The right <head> for the job

Now that we’ve gotten the basic responsive structure out of the way, let’s take a look at the email head. There are several differing opinions about the best DOCTYPE, HTML attributes, and meta tags to use in your emails. Below, we’re listing the ones we’ve chosen to use and why. If you’d like to learn more about email boilerplating, you can check out this interesting discussion on the Litmus community forum.

<!DOCTYPE html>

We’ve chosen HTML5 as our DOCTYPE. This DOCTYPE tells the browser/email client to render the layout in standards mode, not quirks mode, and it’s required for standards validation. It is technically experimental, but in email testing and W3C validation, we haven’t run into any issues.

<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

The Content-Type meta tag is what controls the display of different character sets. Usually you’ll want to use utf-8.

How we did it: Responsive Email Design 2018-02-12T18:59:57+00:00

How we did it: Responsive Email Design

Next week, we’ll be launching a brand new set of default email templates for CheddarGetter. We learned a ton about coding and designing responsive and highly-deliverable emails through the process.

From the get-go, we had a few goals for the new templates in mind:

  • High Deliverability
    We didn’t want these transactional emails ending up in spam.
  • Responsive Design
    We wanted the new templates to look great on every device.
  • Ease of Customization
    We wanted our customers to be able to customize the templates while still maintaining responsiveness and deliverability.

A basic responsive structure

You’d think accomplishing these goals would be pretty straightforward. Unfortunately, coding emails is hard. We knew we wanted to create something mobile-first, but we weren’t quite sure what the best practices were or where to get started. THANK GOODNESS there are awesome resources out there. We really liked the mobile-first, single column approach we found here. Since notifications we send are transactional emails, not visually dynamic marketing emails, a single column structure works really well. It also makes editing the content a little less complicated.

According to FogCreek’s approach, our single column email should scale to fit smaller screens, but it shouldn’t get too wide to read in desktop clients. A max-width table does a pretty good job of restricting the email’s width in most email clients, but, as is often the case with emails, there are a few clients that don’t support this property: Apple Mail, Outlook, and Lotus Notes.

Apple Mail

While Apple Mail doesn’t support “max-width,” it is one of the few email clients that supports media queries. By creating a style tag in the head and inserting this media query,

@media only screen and (min-width: 541px) {
  .cheddar-content {
    width: 540px !important;
  }
}

we can restrict the .cheddar-content table to 540px wide if the window is greater than 541px wide.

Outlook and Lotus Notes

Neither Outlook nor Lotus Notes 8 support the “max-width” property. Luckily, these rogue clients are mostly used to view emails from desktop computers, so we don’t need to be as concerned with responsiveness here. A fixed-width table does the trick. We’re applying a few conditionals: (IE) covers Lotus Notes and earlier versions of Outlook, while (gte mso 9) covers Outlook 2007+. There’s also an identical conditional in the footer of the default notifications that contains all the close tags for this table.

<!--[if (gte mso 9)|(IE)]>
  <table width="540" align="center" cellpadding="0" cellspacing="0" border="0">
    <tr>
      <td>
<![endif]-->

The right <head> for the job

Now that we’ve gotten the basic responsive structure out of the way, let’s take a look at the email head. There are several differing opinions about the best DOCTYPE, HTML attributes, and meta tags to use in your emails. Below, we’re listing the ones we’ve chosen to use and why. If you’d like to learn more about email boilerplating, you can check out this interesting discussion on the Litmus community forum.

<!DOCTYPE html>

We’ve chosen HTML5 as our DOCTYPE. This DOCTYPE tells the browser/email client to render the layout in standards mode, not quirks mode, and it’s required for standards validation. It is technically experimental, but in email testing and W3C validation, we haven’t run into any issues.

<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

The Content-Type meta tag is what controls the display of different character sets. Usually you’ll want to use utf-8.

<meta http-equiv="X-UA-Compatible" content="IE=edge" />

This tag forces Windows Phone 8 (and anything else rendered with IE) to render in highest capable standards available, allowing CSS3 and preventing rendering in quirks mode.

<meta name="viewp0rt" content="width=device-width" />

Since we want our email to be responsive, we’re letting the browser/email client know that our layout will adapt to the device width. NOTE: We’ve purposefully misspelled viewport in our code example above to combat a mobile rendering issue we’re having with our blog (Spelled correctly, it was somehow being read as real code, and overriding the true viewport setting. Weird, huh?). You should definitely spell it correctly in your real email code.

<title>{$subject}</title>

Emails without a title will trigger W3C validation errors. Also, some email clients (like Gmail) actually use the title tag. We’ve added the subject of the email as the title as a default.

<link href="https://fonts.googleapis.com/css?family=Open+Sans:700,400" rel="stylesheet" type="text/css"/>

B-B-B-ONUS: We’re using a webfont! This doesn’t work across all email clients (and, in the case of a few versions of Outlook, requires a bit of a hacky fallback, adding .cheddar-body-text to all parent text elements to prevent everything getting all Times New Roman-y), but it does make the default emails feel much less generic. You can learn more about using webfonts in emails (and which clients support them) in this article by Litmus.

<!--[if mso]>
<style type=”text/css”>
  .cheddar-body-text {
    font-family: Helvetica, Arial, sans-serif !important;
  }
</style>
<![endif]-->
<style  type="text/css">
  @media only screen and (min-width: 541px) {
    .cheddar-content {
      width: 540px !important;
    }
  }
</style>

We know, we know, this looks absolutely insane. TWO STYLE TAGS?!? The first, with the “if mso” conditional, is a fallback for the webfont. If left out, many Outlook clients will default all text to Times New Roman, and it looks gross. The second style tag is for our Apple Mail “max-width” media query. We DID try to insert the conditional with the font fallback inside a single style tag, but it caused a LOT of rendering issues in testing. Luckily, these two tags don’t interfere with each other. Outlook ignores the second <style> tag (whether that’s because it just doesn’t accept two style tags and only applies the first, or if it gets ditched because of the media query, we’re not quite sure). And all non-Microsoft clients ignore the first style tag because of the “if mso” conditional.

Giving it some style

So, we’ve got the basic bones of a great, responsive email. Now it’s time to give it some style. Unfortunately, many email clients don’t allow <style> tags or imported stylesheets in the <head>. The most reliable way to style emails is with inline styles applied to parent elements, and only using <style> tags for specific reasons. To take the brutal copy/paste mundanity and general disorderly appearance out of this process, we’ve used Smarty assign variables that make changing these styles and adding them inline much simpler. These assign variables also make it a lot easier for our users to customize things like their brand colors and fonts. By changing them in once place, where they’re declared in the head, Smarty cascades these styles to the individual elements, adding them as the inline styles that email clients prefer. You can learn more about assign variables in Smarty’s article on Built-in Functions

Testing 1 – 2 – 3

Once we completed our basic template structure and added the styles we wanted, we tested, tested, and tested some more. For comprehensive email testing, we subscribed to http://www.litmus.com. It can be a little pricey, but it makes previewing your emails across a wide range of clients SO much easier. Certain gaps in compatibility came to the surface during the testing process. For example, not all email clients support the border-radius property we applied to the header (we’re looking at you, Outlook). Though obnoxious, that sort of style inconsistency isn’t the end of the world. A more disconcerting discovery was that we couldn’t successfully apply the conditional Outlook font fallback inside the same style tag as the Apple Mail width fix, hence the double style tag craziness. Once the defaults passed Litmus testing (pointy corners in Outlook aside), the emails were good to go!

Find out more about our new templates and how to use them in our Notification Templates Knowledge Base article.

How we did it: Responsive Email Design 2015-06-15T13:56:58+00:00

Scheduled Maintenance For June 8th

Security is a top priority for us here at CheddarGetter. Recently, the US Computer Emergency Readiness Team issued a vulnerability advisory for the RC4 encryption algorithm currently used by our load balancer. While this vulnerability potential only allow access to 100 bytes of data for every 1 billion connections, it is still advised that security focused companies like CheddarGetter move away from RC4.

On June 8th from 8am-9am ET we are scheduling a maintenance window to reconfigure our load balancer to disable use of the RC4 cipher suite and add support for TLS 1.2. We anticipate this will result in downtime of less than 10 minutes, likely much less.

We are typically able to make most configuration changes without any downtime due to our redundant server configuration. However, since this change is to our front end load balancer, we want to be safe. We are scheduling the window from 8am-9am in the event we encounter any issues while reconfiguring.

As usual, if you have any questions or concerns, please don’t hesitate to contact our team via our support forum, Twitter, or Facebook.

Thanks for growing with us,

Team Cheddar

Scheduled Maintenance For June 8th 2015-06-01T07:52:16+00:00

CheddarGetter is getting a new look!

As many of you know, we’ve had a brand new version of CheddarGetter in beta testing for a few months. Today we’re excited to announce that the official cut over to the new CheddarGetter will be next week.

On April 14th, CheddarGetter will become mobile friendly from top to bottom, receiving a total overhaul of the user interface. A new dashboard will be made available that includes key subscription metrics – like churn, LTV, conversion rate, and MRR as well as game changing metrics like LTV by market source.

Countless other improvements will launch, including significant performance upgrades to search, huge improvements in customer communication template building, and streamlined interfaces for customer management. Alongside all the product improvements, we’ll also be launching our revamped branding and a new marketing website.

While we don’t anticipate any significant downtime as a result of the upgrade, we’ve scheduled a maintenance window for April 14th from 8am-10am EDT.

You can test out the new version right now at https://neato.cheddargetter.com. You can also currently test integrations by pointing your development systems to neato.cheddargetter.com.

For a short time after the cut over, the previous version of CheddarGetter will remain available at http://legacy.cheddargetter.com. If for any reason you have issues that necessitate use of the legacy verson, please let us know.

We’re always seeking to ways to improve CheddarGetter and look forward to your feedback!

CheddarGetter is getting a new look! 2015-04-08T14:56:30+00:00