Send a monthly product update email

Kite builds the list of changes from the place your team already records its work. In GitHub, it reads the pull requests merged during the month, including their titles, descriptions, authors, and merge dates. In Linear, it reads the issues your team moved to Done, including their descriptions, labels, comment threads, and attached screenshots. When a title is too terse to explain the change, Kite reads the description and related files, such as a README or an existing changelog, to understand what the change actually does.

Most of a month's work is invisible to customers, so Kite sorts it before writing anything. Say your team merged 31 pull requests in October. Most of them are dependency updates, test fixes, and code cleanup. Four change what a customer can do: recurring invoices, an hourly QuickBooks sync that used to run once a day, faster PDF exports, and a fix for the date filter on the payments report. Those four become the email, and the rest stay out of it.

If your team doesn't use GitHub or Linear, or you'd rather not connect them, Kite works from what's public. It reads your changelog page, your release notes, and your documentation. You can also just tell Kite what shipped, such as "This month we launched recurring invoices and fixed the date filter on the payments report."

Kite picks the lead story by matching what shipped against what customers have been asking for, because the change customers requested is the one they'll open the email to read about. It looks for those requests in several places.

• Your knowledge base. Kite records customer feedback there as it works, along with your research on who your customers are and what they need.
• Your team's Slack conversations. Once you add Kite to Slack, it reviews new messages in the channels it has joined, so it sees when sales or support mentions that customers keep asking about something.
• Feature requests in Linear. If your team files customer requests as Linear issues, Kite can tell which closed issues people were waiting for.
• What you tell it. A quick note such as "Three customers asked about recurring billing on calls this month" gives Kite the context only you have.

The same comparison finds the features your customers don't know about. Suppose support keeps getting asked whether the product handles multiple currencies, and multi-currency invoicing shipped in March. That's a feature customers need to hear about again, so Kite adds a short "in case you missed it" section with a link to where the setting lives. This is often the most useful line in the email, because it answers a question customers are already asking.

Kite rewrites each change as something the reader can now do, because customers care about their work, not your code. A pull request titled "Add RecurringInvoice model and scheduler" becomes "You can now set any invoice to repeat monthly, and it sends itself on the date you choose." A Linear issue titled "Fix tz offset in payments date filter" becomes "The date filter on the payments report now shows the right days for customers outside your time zone."

Kite then shapes the email around the lead change. The lead gets a short paragraph that explains the problem it solves and a link to try it. The smaller improvements and fixes follow as one line each, and the feature they may have missed comes after those. Every item links to the place in your product or documentation where the customer can see it.

Kite writes the subject line and the preview text, which is the short line many inboxes show after the subject. Together they name the lead change in plain words. Kite also keeps each month's subject line different from the ones before, so the email doesn't look like the same message customers ignored last time. It signs the email as the person you name, such as your founder or product lead. When you don't name anyone, it signs as your team.

Kite brings you the draft along with its plan for the email, so you can judge the draft against what it was meant to do. The plan names the lead change and why Kite picked it, the proof behind it, the subject line, and where each link goes. If you'd rather lead with a different change, tell Kite, and it rewrites the email around that one.

For ideas on how other teams format their changelogs and update emails, see Changelog Examples: Product Update Pages and Emails Small SaaS Teams Can Copy Coming soon .

Kite sends the monthly email through the email platform that already holds your customer list, because that platform keeps your subscribers, their preferences, and their unsubscribe links in one place. What Kite does next depends on which platform you use.

• Mailchimp. Kite creates the campaign, chooses the audience or segment, and sets the subject line, preview text, and sender name. It runs Mailchimp's send checklist and fixes what it flags, such as a broken merge tag. It can send a test email to your inbox, then schedules the campaign for the time you agreed on or sends it right away once you approve it.
• Resend. Kite creates a broadcast for the segment you choose, such as everyone on a paid plan. If you use Resend's topics so contacts can choose which emails they get, Kite builds the segment from the people subscribed to product news, so only they get the update. It sends the broadcast or schedules it for a set time once you approve it.
• Brevo. Kite writes the content, subject line, and recipient lists into an email campaign you've started in Brevo. Your team then sends or schedules the campaign from Brevo.

Segments let you match the email to the reader. If a feature is only on your higher plan, Kite can send customers on that plan a version that includes it and send everyone else a version without it. Before any send, Kite checks the records it has for people who unsubscribed or asked not to be emailed, and leaves them off.

Kite asks before it sends an email. You approve the draft with the Approve button or a reply in the conversation, in the Kite web app or in Slack.

After each send, Kite reads how the email performed and uses the results to plan the next one. In Mailchimp, it reads opens, clicks on each link, and unsubscribes. In Resend, it reads delivery, opens, and clicks for the broadcast and ranks the links readers clicked most. In Brevo, it reads the campaign's statistics. When your changelog or documentation lives on a website Kite hosts, it also reads the visits those pages got from the email.

Kite turns those numbers into decisions. If most clicks went to the "in case you missed it" feature rather than the lead, Kite knows that reminders about existing features earn attention from your customers and gives them more room next month. If customers clicked the documentation links and ignored the blog post, the next email sends them straight to the docs. Kite records what it learns in your team's knowledge base, so each month's email starts from what already worked with your customers.

You can ask Kite to run the whole job every month, so the email goes out on time even in a busy month. Tell Kite the day you want the draft, such as the last Thursday of each month, and it sets up a recurring job in your time zone. Each run reads the month's changes, checks what customers asked for, writes the email, and brings it to you for approval.

The draft arrives as its own conversation in the Kite web app. For a team without Slack, Kite also emails it from your team's Kite address to the person who set up the schedule, and replying to that email continues the conversation. For a team with Slack, it goes to the channel you choose. Once you trust the drafts, you can give Kite more room to send the email on its own.