Framing as Organizational Memory: a Shape Up Case Study
Framing is how we decide what’s worth solving. When we build something new, that means framing one or multiple problems on a blank canvas. When we change something that already exists, it means more: the thing already does several jobs, the affordance of each sitting somewhere between obvious, easy, and possible, and a new job can’t be added without rebalancing the others. Without rebalancing, in the worst case scenario, we end up destroying the existing jobs.
What follows is a small case study: adding a sales message to “Welcome to City,” a logistical email a travel company sends travelers five days before their first tour. It shows what happens when an organization forgets why an existing thing exists, and how we recovered that memory before changing it. With agentic engineering, we can now build very quickly, including the wrong thing, so framing kept as organizational memory matters more than ever.
Welcome to City email
Here is the original email:
The motivation for the change was to generate more sales. We wanted to add sales messages to this email so we could sell small-group tours last-minute. We also wanted to communicate with the travelers that they could add more people to the tours that they are going to take in the next several days, if we knew we could.
As a quick CMS-based fix, we actually did half of it, by changing this section in the middle of the email from:
to the following (notice “Have a little room in your itinerary?”):
We could extend this kind of change - say, replace the section with a graphical banner that says “Have a little room …” far more prominently.
We paused there, because we thought making it prominent would break what the email was originally intended to do for travelers.
What the Artifact Does
Here are the pieces in that email:
Counts down and sets the scene. It shows "5 days until Rome!" with a hero photo of the city.
Greets and welcomes. It addresses the traveler by first name and says Context is thrilled to be part of the trip.
Recaps the booking. Under "Your Experience in Rome," it lists each booked tour as a card with a photo, the tour name, the date and time, and a "More Info" link.
Points to My Experiences. It shows a "My Experiences" button.
Lists what's there before the tour. It says the page holds the meeting point and pre-tour information, and that the guide's name, bio and phone number appear around 7 PM the day before (morning tours) or 7 AM the same day (afternoon tours).
Lists what's there after the tour. It says the traveler can tip the guide (if cashless tipping is on), leave a review, and send a free postcard with a photo and a note.
Offers reading. Under "Local Gems & Must-Know Tips," it links to three blog posts: things to do in Rome, a read/watch/listen list, and an insider's guide from Context experts.
Explains support. Under "Our Commitment to You," it gives the Last Minute Support Team for issues within 48 hours, plus the client services email and an SMS number.
Explains guide contact. It says the guide will reach the traveler by SMS and email around 7 PM the day before or 7 AM the day of, and asks the traveler to use that number only for day-of needs and to turn on international texting.
Signs off. "Thank you for choosing us... See you soon, Context."
Footer. Social icons, copyright, address, and links to Visit, Contact, FAQ, Privacy and Cancellation Policy.
Measured by height, each piece takes up:
For example, “My Experiences” related pieces occupy 21% when the traveler has one tour in the coming days, 17% when there are three tours. Every email strikes some balance among its pieces.
Reverse-engineering the Original Framing
We could not find any documentation on this email’s original framing - what jobs it should do in what balance. Based on the timing of the email delivery (5 days before the first tour during the trip), and what we learned from 40+ customer interviews, we reverse-engineered the original framing so we can understand why this email should exist in the world.
They feel sure their tours are confirmed and ready.
They know what they booked and when, without digging through their inbox.
They know how to reach us if something goes wrong on the ground.
They know when and how they'll get tour-specific details (meeting point, guide).
They have ideas for the time between tours, if they want more.
Notice that these are written from the traveler's side: progress belongs to the people it's for, not to the artifact. Traveling somewhere unfamiliar is exciting, but it's often overwhelming too. Anxieties and hiccups coming from logistical burdens should be minimized - travelers' time at the destination is precious. On the affordance spectrum of Obvious, Easy, and Possible, the email should afford Job 1 and Job 2 as Obvious, Job 3 and Job 4 as Easy, and Job 5 as Possible.
The question is, does the email actually reflect the jobs that travelers would want to get done?
The email does Job 1. Job 2 is good, too - especially for travelers with several tours, who would otherwise dig through several emails in their inbox. Job 3 is good, but it comes eighth and ninth of eleven pieces, and some travelers never receive the SMS the ninth promises. As for Job 4, yes, they can access the details by clicking the tour card link, but the details are behind a login wall and many of them don’t have one. Job 5, which is clearly secondary, comes before half of Job 4. And 17-21% of the space is used to explain what My Experiences pages do for them before and after tours. The email artifact is describing the other artifact.
The email is doing the jobs, but not in the way the framing tells us.
Rewriting the Whole Email
The email's framing and balance are now clear at the conceptual level. As for the sales messages we want to add, anxious travelers who don't trust us won't buy anything more from us. Trust first, commercial as a consequence.
[Obvious] They feel sure their tours are confirmed and ready.
[Obvious] They know what they booked and when, without digging through their inbox.
[Easy] They know how to reach us if something goes wrong on the ground.
[Easy] They know when and how they'll get tour-specific details (meeting point, guide).
[Easy] They know they can add people or experiences to their trip, if they want. <- Inserted.
[Possible] They have ideas for the time between tours, if they want more.
The framing itself barely changed: one new job, slotted in as Easy, with the old Job 5 still Possible below it. The artifact is a different story. Its balance had drifted so far from the framing, old or new, that inserting one more piece would only add to the drift. So we decided to rewrite the whole email.
Shape of the Email
Now that we have established the new framing and its balancing, we can rewrite the email. Most of it is copywriting, but a few mechanisms are needed to achieve those items in the framing. Here's the outline of the new email:
List of tours they booked for the trip -> Jobs 1, 2
"We've got you" for assurance. Logistical information - contact method, when to know what and how, etc -> Jobs 3, 4
"You can add participants" (shown only for tours that can easily take more people) -> Job 5
Last-minute small-group tours at 20% off (shown only if there's small-group availability during their trip in the city, AND in frequently visited companion cities) -> Job 5
Sign-off
P.S. with inspirations -> Job 6
The purpose of this write-up is to demonstrate the importance of framing as an organizational memory. So I won’t go into the shaping of each item. The new email below looks straightforward to travelers, but getting there took a lot of back-and-forth between framing and shaping before we built anything, especially on the supply side. Above, I have intentionally hidden the supply side framing so you’d only see the demand-side framing. Let me pick one Shape item to show what it took to make the entire change happen.
One level down, the small-group offer (Shape #4) has three pieces before we render the text of the section:
A mechanism that checks if there is small-group availability during a specific time window in a specific city
A mechanism that determines frequently visited companion cities for a given city
A discount mechanism
The first, checking availability, is straightforward - it’s basically a database query. The second one isn’t difficult either - from past purchase data, we can calculate common city pairs - like “% of customers who purchased a tour in Rome purchased tours in Florence for the same trip.” And we don’t have to calculate each time we generate the Welcome to City email - do the pairing calculation for all cities we serve once a year and put it in a configuration file. No problem. The third one is trickier. In the age of agentic engineering, it costs much less to implement something than before, but still, we need to unpack what a discount mechanism means.
On the travelers’ side, it simply means they can get 20% off certain tours, whether through a personal promo code, a special URL or something else. On the supply-side, since we are a for-profit entity, we can’t give 20% off everything. I spoke to my business counterpart, and distilled the discount boundary into:
Time-horizon - the discount is applicable for tours that run from the day the email is sent through 7 days after their first tour in the trip.
Product-horizon - any small-group tour (but not private tours)
Spatial-horizon - in any cities we serve
The time-horizon is a combination of the demand-side circumstances and the supply-side ones. We need to make the offer relevant to travelers’ circumstances during the trip. We also need to limit the temporal scope - we would not want to make the offer applicable for tours further in the future. The spatial-horizon is mostly demand-side, because some travelers (not the majority but a meaningful number of them) follow a travel corridor, visiting several cities in one trip, so there’s no point limiting the offer to one single city. On top of these, the supply side has its own needs, like tracking every promo code the system issues. These boundaries are framing too, and they’re exactly what a future team would need to remember before changing the implementation. Some of these belong in the framing from the start. Others only appear during shaping: choosing a promo code as the delivery mechanism, for example, created the need to track codes, which then had to be carried back into the framing. That back-and-forth between framing and shaping deserves its own write-up.
With that, we were ready to build. I’ll skip the building and go straight to the new artifact.
The New Email
The new email as a whole looks like this:
It has:
Countdown, greeting, and welcome
List of tours - for Jobs 1, 2
“We’ve got you” for Jobs 3, 4. It now comes in two versions, one for travelers who get SMS from their guide and one for those who don’t, so it no longer promises a message some travelers never receive. The tour links no longer require a login, so the details are actually reachable.
"You can add participants" would have been for Job 5, but in this case, we knew we could not take additional guests to those three tours, so the additional participant section is not shown.
Last-minute small-group tours at 20% off for Job 5
Sign-off
P.S. with inspirations -> Job 6
The order follows the spectrum: the Obvious jobs come first, the Easy ones next, and the Possible one sits in a P.S. Wherever a traveler stops reading, they’ve already gotten what matters most.
What’s gone matters as much as what’s there. The explanation of My Experiences, before and after the tour, and the post-tour asks to tip, review and send a postcard, about a quarter of the old email’s fixed content, are no longer in it. The email no longer describes another artifact; it does its jobs directly.
Let’s have a closer look at the commercial paragraph “See a little more of Rome - 20% off”:
It starts with “Since it’s the two of you, a small-group tour is a ….” It is context-dependent - if solo, or a bigger party, it will show a different sentence so it can tell the reader what a small-group tour would mean to their circumstances, based on what we learned from the 40+ customer interviews.
“Use code CERAMIC067 at checkout …. through September 18.” The dynamically inserted promo code is programmatically configured to meet the three horizons.
“Explore Rome’s small-group tours” links to a page that is a date-oriented product viewer, which only shows what’s available.
“Also visiting Florence? Your code works on small-group tours there too.” This line is shown if commonly paired cities have small-group availability.
It isn’t a world-changing email. But every piece of it now traces back to a job, and it no longer tells anyone something that isn’t true.
Real-world Outcome
How did the new email change travelers’ behavior? We happen to have something close to a counterfactual. A few weeks before the rewrite, our marketing team had already added a commercial line to the old email: “Have a little room in your itinerary?”, linking to the same last-minute small-group tours. Same message, same destination. The only real difference was the email around it.
Two things changed.
First, travelers reached their tour details far more often: visits to their experience pages roughly doubled. That’s probably mostly because we removed the login wall, but the decision to remove it came from the framing, not from the technology. The framing said travelers shouldn’t have to dig for what they booked, and the login was in the way.
Second, the commercial message started working, though not in the way you might expect. The share of travelers clicking the offer stayed roughly the same. What changed was what happened after the click. With the old email, every traveler who clicked left without looking at a single tour, and none of them bought anything. With the new one, many went on to view a tour, a meaningful share explored departure dates, and some booked. The click rate barely moved, but what travelers did after the click changed completely. What surprised us was that most of the travelers who booked chose private tours, which weren’t eligible for the discount, rather than the discounted small-group tours. So the discount was probably not the main driver.
The data can’t tell us which changes led to the bookings. Was it the copy or the promo code in the sales section? The page it links to, which shows only what’s available? The logistics, now clearer and easier to reach? Or some combination? We could have run A/B tests to separate them, but we chose not to, because finding the best mix conclusively would have taken time and attention. Instead, we fit the email as well as we could to the travelers’ circumstances, as captured in the jobs, measured what changed, and moved on.
So we don’t know whether the principle we started from, trust first, commercial as a consequence, is what worked, and we never will. That’s okay. We have plenty of other things to improve.
Framing as an Organizational Memory
Framing, the idea Ryan Singer introduced to help us decide what matters, is becoming even more important now that agentic engineering is in our tool belt. We produce more software and change it more often. Drift happens whenever we aren’t careful, with or without AI: as the original Welcome to City email shows, an artifact can quietly drift over time, until it serves its own parts instead of the people it was for.
Keeping framing as an organizational memory guards against that drift, and lets us build on an existing product meaningfully. Whenever we change something, we should first look at its framing and decide whether to build on it or rewrite it. If no framing was written down, we can recover it, but from the customer’s progress, not from the artifact, because the artifact already contains the drift.
Framing is the ultimate test suite for what we make.