Zaptime cut deliverability tickets from dozens a month to zero with Lettr
How Zaptime, a scheduling and booking platform, moved its transactional and marketing email from two vendors onto Lettr in a one-day migration: the missing booking confirmations behind the switch, why Lettr's domain API and EU hosting decided it, and the drop from dozens of deliverability tickets a month to zero.
Zaptime is a scheduling and booking platform for teams, with booking pages, calendar and video-call integrations, payments, CRM sync, and automated email workflows. It is fully localized, and customers can manage their scheduling from AI assistants like Claude and ChatGPT through Zaptime's MCP server. Every reservation triggers a confirmation, reminders, and a payment receipt sent from the customer's own domain, so email is a core part of the product.
This case study covers how Zaptime moved both its transactional and marketing email onto Lettr in a single day of engineering, and how its deliverability tickets went from dozens a month to zero.
The challenge: missing booking confirmations and no diagnostic data
Before Lettr, Zaptime ran two separate email stacks: Amazon SES for booking messages and a separate tool for its own marketing. Support tickets showed that customers' clients were missing booking notifications, and SES offered nothing to explain why beyond raw bounce notifications.
Custom sending domains were a second weak point. Each customer team sends from its own domain, and Zaptime verified those domains through a fragile, do-it-yourself flow. The marketing tool kept its own contact database, which made consent and unsubscribe preferences difficult to connect to Zaptime's app.
Zaptime first tested a popular transactional email API, which fell short on two requirements. It could not manage sending domains programmatically for hundreds of customer teams, and its EU data residency did not meet the needs of a customer base that is mostly European.
The solution: one platform for booking emails and marketing
Zaptime chose Lettr, which handles both kinds of email from one account: the transactional booking emails Zaptime's customers send to their clients, and Zaptime's own marketing to those customers.
The deciding factor was domain management through the API. Lettr's domain API creates and verifies each customer's sending domain, so Zaptime shows the required DNS records in its own UI, and Lettr reports delivery data for every message.
Lettr also met two other requirements. It is hosted in the EU, which many of Zaptime's customers require for data processing, and its official Laravel package matches Zaptime's stack.
The whole migration (transactional sending, custom-domain enrollment, contact sync, and the preference-management UI) took a single day of engineering. Both providers ran side by side during the switch, so Zaptime's customers saw no disruption.
Tomas Senk, co-founder of Zaptime, on the setup:
Support was fast, technical and genuinely helpful. When we were setting up custom sending domains for our users, the Lettr support engineer walked us through the DNS records and verification flow. It felt like working with a partner.
The outcome: zero deliverability tickets
Booking emails now reach inboxes reliably. Every outgoing email is tagged with its trigger and customer team, so delivery and engagement are visible per customer, and users manage their email preferences directly in Zaptime's app.
Tomas Senk on what changed for the team:
Before the migration, Zaptime was getting dozens of tickets a month. Afterwards, the number dropped to zero, freeing our engineers to spend their hours on more important tasks. For a team our size, that is the biggest win.
Zaptime's next steps build on the same setup: surfacing delivery and engagement data inside its own product, driving lifecycle campaigns from typed contact properties such as plan and trial end, and moving its remaining SES domains over so that Lettr becomes its only email provider.
FAQ
How long did Zaptime's migration to Lettr take?
Can one Lettr account send both transactional and marketing email?
Can Lettr create sending domains for my own customers through the API?
Where does Lettr host its data?
Bottom line
Zaptime's deliverability problems came from two gaps: no visibility into why booking emails went missing, and a do-it-yourself flow for customer sending domains. Moving both kinds of email onto Lettr closed both in one day of engineering and brought deliverability tickets to zero. To try the same setup, create a free Lettr account, or read the sending domains docs to see how per-customer domains work.