3 ms·

> Out of curiosity, does your system use a NoSQL database? No, the last system I built was using PL/PGSQL. It's brilliant for this application. > The billing

> Out of curiosity, does your system use a NoSQL database? No, the last system I built was using PL/PGSQL. It's brilliant for this application. > The billing table has "CustomerID, ResourceID, HourID, Units, SKU_ID" columns. You raise or lower your prices on the hour boundaries. The new rows inserted after the price change will have the new SKU ID with the new costs. Like I said, this is a very simplistic way of viewing how to do billing. Sure, today you only have the hour dimension when choosing a price. But then sales asks you to give a discount to a specific, very large, customer. For only a single resource. For only the first three months. Suddenly, and very predictably, your billing is not so simple any more. The problem is not that simple billing is difficult. The problem is that billing is not simple.

Maxion 4y ago
> Like I said, this is a very simplistic way of viewing how to do billing. Sure, today you only have the hour dimension when choosing a price. But then sales asks you to give a discount to a specific, very large, customer. For only a single resource. For only the first three months. Suddenly, and very predictably, your billing is not so simple any more. I'm not sure if I'm missng some part of the complexity here, but with the solution jiggawatts proposed, wouldn't the above scenario be fairly trivial to solve? Just implement a new SKU for this special one-time (more like first time...) discount that the account manager applies to the account. If you want to be fancy, you could code in (or leverage one of the dozen cloud tools, depending on where you're deployed) to enable the SKU for the customer at period X and remove it at period Y and replace with the previous SKU. To ease reporting, in your main SKU table you could have a parent_sku column and a sku_type column explaining that this row is a special discount child SKU of the parent_sku. Add basic databse restrictions and validations. Billing is complex and requires lots of domain knowledge, but IMO it's not really THAT hard from my experience. EDIT: IMO a harder scenario for any billing system to deal with is account manager A made a sweetheart deal to make customer B less angry, removing one SKU completely from last months bill, giving them a 25% discount for the next invoice, and giving them some freebie. These types of requests usually end up with a lot of issues unless the business logic promised to the customer already exists.
- doctor_eval 4y ago
  Well, the problem with the first scenario is that if the discount is percentage based (say, 10% off), then it's going to require code to calculate. It's no longer just an SKU - it's an SKU which does a calculation, which is presumably not part of the platform already. And so we have a new "discount" SKU - but which line items should the SKU apply to? How do we know when to stop using that SKU when the discount runs out? And anyway, why should an SKU have a discount % field on it? Why do we get different behaviours based on some magic SKU field? It's a breakdown in cohesion... and so the spaghetti begins... You can also argue that we can just "get someone" to apply discounts manually, but isn't that the job of the billing system? Manual labour doesn't scale too well, and a lot of mistakes get made - asking a customer to return an accidentally applied discount is a very, very difficult conversation, and I've worked with companies who simply had to absorb years of incorrect discounts because doing so was the only way to keep the customer.
  - donavanm 4y ago
    Dont forget co-selling discounts. First 100 messages free with a monthly resource. And is that per monthly resource, or each monthly resource?
  - AnhTho_FR 4y ago
    Also, here is an example of 'looks simple' but 'raises many question' 1/ Should it be a discount on future invoices, or a refund (an angry customer will ask for a real refund: aka $$ on their bank account)? 2/ Do you want to keep track of how much has been discounted/refunded to which customer (so that you can identify deeper trends: if a segment is being discounted many times: maybe you can adjust things, or maybe it's fraud?)? In that case, just erasing a line doesn't help 3/ If you refund, how do you deal with taxes that have been paid already? Btw, we've written a quick primer on Refunds, Coupons, and Credit Notes: to lay out the pros/cons https://github.com/getlago/lago/wiki/A-Primer-on-Refunds,-Coupons-&-Credit-Notes https://github.com/getlago/lago/wiki/A-Primer-on-Refunds,-Co...
    - doctor_eval 4y ago
ofrzeta 4y ago
The problem, apparently, is, that even in the largest software installations there are a lot of snowflakes to be taken into account (your "very large customer").
- doctor_eval 4y ago
  Yeah, as engineers we want to say "well tell them we can't do it". But in reality, if the customer represents 25% of your income and they are dead set on getting their way, what you are really saying is that we should lose the customer - which translates to, "we have to sack a quarter of our team". (I had a CEO who used to use exactly this analogy with us).
  - chasd00 4y ago
    > "well tell them we can't do it". hah yeah i've tried that a couple times over the years, it never worked. Another aggravating thing i ran into is in the industry i was working in (pharmacy) prices are calculated using a contracted formula. The pharmacy (my system) calculates a price and then sends the rx to the insurance company. They calculate using the same formula (hopefully) and if their result matches or comes out greater than what we calculated then they pay the invoice. However, if their calculation came up less than what we sent they'd pay their amount. It was a cat and mouse game constantly. Well one very large insurance carrier had a bug in their system that under the right conditions would come up a dollar short for a very common rx. I understood what was happening and called and called and bugged them to fix the issue. Finally, they just ended up saying "we're not going to change the system. end of story.". It blew my mind, I was right out of college and too naïve to consider they'd just flat out refuse to fix the bug.
    - doctor_eval 4y ago
      I actually saw something similar in telco, where a carrier was rounding charges to the cent, but charging in fractions of a cent. So for example a CDR might be worth $0.001 but my customer was being charged $0.01. My customer complained, but in this case they prevailed because the contract said nothing about rounding. This can be really significant. They ended up having to compute the charges and send the carrier a bill for the difference. It was worth tens of thousands of dollars per month.
AnhTho_FR 4y ago
> The problem is not that simple billing is difficult. The problem is that billing is not simple. Love this quote!

Maxion 4y ago

> Like I said, this is a very simplistic way of viewing how to do billing. Sure, today you only have the hour dimension when choosing a price. But then sales asks you to give a discount to a specific, very large, customer. For only a single resource. For only the first three months. Suddenly, and very predictably, your billing is not so simple any more. I'm not sure if I'm missng some part of the complexity here, but with the solution jiggawatts proposed, wouldn't the above scenario be fairly trivial to solve? Just implement a new SKU for this special one-time (more like first time...) discount that the account manager applies to the account. If you want to be fancy, you could code in (or leverage one of the dozen cloud tools, depending on where you're deployed) to enable the SKU for the customer at period X and remove it at period Y and replace with the previous SKU. To ease reporting, in your main SKU table you could have a parent_sku column and a sku_type column explaining that this row is a special discount child SKU of the parent_sku. Add basic databse restrictions and validations. Billing is complex and requires lots of domain knowledge, but IMO it's not really THAT hard from my experience. EDIT: IMO a harder scenario for any billing system to deal with is account manager A made a sweetheart deal to make customer B less angry, removing one SKU completely from last months bill, giving them a 25% discount for the next invoice, and giving them some freebie. These types of requests usually end up with a lot of issues unless the business logic promised to the customer already exists.

doctor_eval 4y ago
Well, the problem with the first scenario is that if the discount is percentage based (say, 10% off), then it's going to require code to calculate. It's no longer just an SKU - it's an SKU which does a calculation, which is presumably not part of the platform already. And so we have a new "discount" SKU - but which line items should the SKU apply to? How do we know when to stop using that SKU when the discount runs out? And anyway, why should an SKU have a discount % field on it? Why do we get different behaviours based on some magic SKU field? It's a breakdown in cohesion... and so the spaghetti begins... You can also argue that we can just "get someone" to apply discounts manually, but isn't that the job of the billing system? Manual labour doesn't scale too well, and a lot of mistakes get made - asking a customer to return an accidentally applied discount is a very, very difficult conversation, and I've worked with companies who simply had to absorb years of incorrect discounts because doing so was the only way to keep the customer.
- donavanm 4y ago
  Dont forget co-selling discounts. First 100 messages free with a monthly resource. And is that per monthly resource, or each monthly resource?
- AnhTho_FR 4y ago
  Also, here is an example of 'looks simple' but 'raises many question' 1/ Should it be a discount on future invoices, or a refund (an angry customer will ask for a real refund: aka $$ on their bank account)? 2/ Do you want to keep track of how much has been discounted/refunded to which customer (so that you can identify deeper trends: if a segment is being discounted many times: maybe you can adjust things, or maybe it's fraud?)? In that case, just erasing a line doesn't help 3/ If you refund, how do you deal with taxes that have been paid already? Btw, we've written a quick primer on Refunds, Coupons, and Credit Notes: to lay out the pros/cons https://github.com/getlago/lago/wiki/A-Primer-on-Refunds,-Coupons-&-Credit-Notes https://github.com/getlago/lago/wiki/A-Primer-on-Refunds,-Co...
  - doctor_eval 4y ago

ofrzeta 4y ago

The problem, apparently, is, that even in the largest software installations there are a lot of snowflakes to be taken into account (your "very large customer").

doctor_eval 4y ago
Yeah, as engineers we want to say "well tell them we can't do it". But in reality, if the customer represents 25% of your income and they are dead set on getting their way, what you are really saying is that we should lose the customer - which translates to, "we have to sack a quarter of our team". (I had a CEO who used to use exactly this analogy with us).
- chasd00 4y ago
  > "well tell them we can't do it". hah yeah i've tried that a couple times over the years, it never worked. Another aggravating thing i ran into is in the industry i was working in (pharmacy) prices are calculated using a contracted formula. The pharmacy (my system) calculates a price and then sends the rx to the insurance company. They calculate using the same formula (hopefully) and if their result matches or comes out greater than what we calculated then they pay the invoice. However, if their calculation came up less than what we sent they'd pay their amount. It was a cat and mouse game constantly. Well one very large insurance carrier had a bug in their system that under the right conditions would come up a dollar short for a very common rx. I understood what was happening and called and called and bugged them to fix the issue. Finally, they just ended up saying "we're not going to change the system. end of story.". It blew my mind, I was right out of college and too naïve to consider they'd just flat out refuse to fix the bug.
  - doctor_eval 4y ago
    I actually saw something similar in telco, where a carrier was rounding charges to the cent, but charging in fractions of a cent. So for example a CDR might be worth $0.001 but my customer was being charged $0.01. My customer complained, but in this case they prevailed because the contract said nothing about rounding. This can be really significant. They ended up having to compute the charges and send the carrier a bill for the difference. It was worth tens of thousands of dollars per month.

AnhTho_FR 4y ago

> The problem is not that simple billing is difficult. The problem is that billing is not simple. Love this quote!