Architecture assumptions log for smoother enterprise deals

Why deals keep restarting

Large prospects rarely ask everything at once. The first call is usually broad. Someone asks where the product runs. On the next call, a security lead wants details about SSO, audit logs, and data retention. A week later, procurement returns with the same hosting questions in slightly different words.

The trouble starts when every answer lives somewhere else. One person keeps notes in the CRM. Another drops context into chat. An engineer replies by email from memory. Before long, the team has three versions of the same story. One says "single-tenant is possible." Another says "shared cloud only." The buyer spots the mismatch fast.

That pulls the deal backward. Instead of moving toward fit, price, or timeline, the team spends another hour repeating technical discovery it already did. Engineers explain data flow again. Security checks the same limits again. Product leaders get dragged in to confirm promises nobody wrote down clearly.

The cost is more than time. Mixed answers make the prospect wonder whether the team can handle an enterprise account at all.

This gets worse when the deal includes unusual requests. Self-hosting, regional data storage, custom retention rules, private networking, or special support terms often begin as a casual "maybe." If nobody records whether that means "supported now," "possible with work," or "not planned," it turns into a promise by accident.

An architecture assumptions log stops that loop. It gives sales, engineering, security, and leadership one shared record of what the prospect asked for, what the team confirmed, what is still open, and who approved any exception. When the next call starts, nobody has to rebuild the same picture from scraps.

Teams that handle complex deals well usually share one habit: they treat technical assumptions like deal facts, not side notes. That saves hours, cuts mixed messages, and makes every later reply sound consistent.

What the log should answer

An architecture assumptions log should make repeat questions easier to answer, not create more notes to dig through. If a new teammate cannot read it and understand the prospect's environment in a few minutes, it is too vague.

Start with the product as it works today. Write down where it runs now, who hosts it, and which deployment models already exist. A line like "single-tenant cloud is possible; on-prem is not supported today" can save a lot of back-and-forth later.

Then describe the data path in plain language. Security questions usually come down to a few basics: what enters the system, where it is stored, which services touch it, and what leaves the system again. If your team cannot explain that in a few clear sentences, different people will answer it differently.

A useful entry should answer five practical questions:

• Where does the product run today, and which hosting options already exist?
• What data comes in, where does it move, and where does it leave the system?
• Which security, compliance, and support limits are fixed for this deal?
• Which requests fit the current product without custom work?
• Which questions are still open, and who owns each one?

That fourth point matters more than teams like to admit. Large prospects often mix standard requests with custom asks in the same meeting. If the log does not separate "supported now" from "possible later" and "not planned," people start making soft promises without meaning to.

Open items also need names, not vague reminders. "Check with security" is weak. "Priya to confirm log retention by Thursday" is useful. That small shift keeps handoffs clean when a salesperson, engineer, and advisor all touch the same deal.

Keep the wording simple. This is not the place for a full system diagram or a long design memo. The goal is a record the team can trust when the next email asks about hosting, data handling, access controls, or support terms.

The fields every entry should include

Each entry should answer one basic question: what does this prospect need, and what has your team already agreed to? If the entry is fuzzy, people fill the gaps from memory, and the same technical call happens again a week later.

Start with deal context. Record the prospect name, current stage, and target launch date. That gives every later note a deadline and a level of urgency. A security review for a deal closing this quarter needs a different response from an early discovery call.

After that, capture the areas that usually create friction: hosting rules, identity and access needs, data handling rules, and any non-standard promise. You do not need a huge template. You do need a consistent one.

For hosting, write more than a short label. Note whether the prospect wants dedicated hosting, certain countries or regions, or limits on where support staff can access systems. If they say "EU only," record whether that applies only to production or also to backups, logs, and support tools. Those details usually surface later, when changing them is harder.

Identity and access notes save a lot of time during enterprise deal documentation. Record the auth method they expect, who manages access, how long logs must remain available, and whether they need exportable audit records. "SSO required" is too thin if the buyer also expects SCIM provisioning or admin action logs.

Data notes should be blunt. Where does data live? How long do they want to keep it? What triggers deletion? If legal, security, and procurement each gave a different answer, write all three and assign someone to resolve the conflict.

The last field is the one teams skip most often: non-standard promises. If someone offered a custom retention policy, private deployment, or security exception, capture the exact promise, the date, the speaker, and the approver. That one habit makes the architecture assumptions log useful during a sales engineering handoff instead of just during the first call.

How to update the log after each call

Update the log right after the call, while names, numbers, and edge cases are still fresh. Waiting until the next day sounds harmless, but that is when memory starts blending facts with guesses.

Start with the raw notes from the latest conversation. Pull out direct facts first: what the prospect asked for, what they already have, what they rejected, and what still needs an answer.

The log works best when each request becomes a short, separate line. If a buyer says, "We need EU hosting, SSO, and a security review before pilot," do not bury that in a paragraph. Split it into three entries so sales, engineering, and security can track them without rereading the full call summary.

A simple structure is enough:

• one request or assumption per line
• a short status
• one owner
• one due date

Keep opinions out unless you label them clearly. "Customer requires data residency in Germany" is a fact if they said it. "They will probably accept another region" is a guess, so leave it out until someone confirms it.

This matters more than it seems. When facts and guesses sit together, sales can promise too much, and engineers can solve the wrong problem.

Every open item needs an owner. If nobody owns "confirm SAML scope" or "review backup retention limit," those items drift until the next call forces everyone to scramble. Pick one person, set one date, and move on.

Before you send the update, trim the wording. Long notes hide risk. Short lines make gaps obvious, which is exactly what you want.

Share the revised log with sales and engineering the same day. A short message and the updated document are enough. Tight follow-up usually saves more time than another internal meeting because everyone reacts to the same facts instead of retelling the call from memory.

How to record hosting, security, and data flow limits

Large prospects often mix hard requirements with preferences. If you record all of it in one vague note, the team argues about the wrong thing and sales can promise more than delivery can support.

Start with the current setup before you write any requested change. Note where the app runs today, who hosts it, where customer data lives, which services touch that data, and which security controls already exist. A short baseline cuts down guesswork.

One simple split keeps these notes clear:

• Required: the buyer says the deal cannot move without it.
• Optional: the buyer wants it, but the deal can still close without it.
• Unknown: someone raised it, but nobody confirmed whether it is mandatory.

That distinction matters. A buyer may ask for single-tenant hosting, private networking, and custom retention rules in one call. Sometimes only one of those items is truly required. The others are nice to have.

Describe the data path in plain words, not diagram language. Write the actual route a record takes: "User submits a file, the API stores it in object storage, a worker reads it, the model processes the content, and logs keep request metadata for 30 days." Anyone on the team should understand that without a second meeting.

Then record every gap between the request and the current system. If the prospect wants data to stay in one region but your backups copy elsewhere, write that down. If they want customer-managed keys and you only support provider-managed encryption, write that down too. Small gaps become deal blockers when nobody captures them early.

End each entry with the smallest promise your team can keep. Skip broad comfort phrases. Write the narrow commitment you can actually deliver, with any limit attached.

For example: "Dedicated hosting is possible for production workloads; private network isolation is not committed in this deal." That gives the sales engineering handoff a firm answer and keeps the next call from restarting the same technical conversation.

A simple example from one enterprise prospect

A large prospect reaches out after a demo and asks for four things at once: EU hosting, SSO, audit logs, and a custom data retention rule. This is where teams often get in trouble. Someone tries to be helpful on the call, gives a rough yes, and engineering later finds the gaps.

A better move is to put each request into the architecture assumptions log while the call is still fresh. Sales records the exact wording, who asked for it, and why it matters. If the buyer says "EU hosting is required for legal review," that note stays attached to the request instead of getting shortened to "wants EU region."

Sales also avoids promising delivery dates on the spot. That keeps the deal honest and saves the team from walking back a casual answer the next day.

Engineering then reviews the same entry and marks each item in plain language. EU hosting might already be possible. SSO may exist for one identity provider but need extra work for the buyer's setup. Audit logs may cover admin actions but not every user event. The custom retention rule may require product changes because the current system only supports fixed retention windows.

The reply back to the prospect stays clear and calm. The team confirms what exists today, names the limits, and lists the open questions. They may ask whether audit logs must export to the buyer's SIEM, whether retention rules apply to backups too, and whether SSO must support SCIM or only sign-in.

Include a review date in that reply. It is a small detail, but it helps more than people expect. It tells the buyer when to expect the next answer, and it gives the internal team a real checkpoint.

On the next call, nobody starts from memory. The same document carries the full history: request, owner, current status, open questions, and last reply. That is why an architecture assumptions log helps with enterprise deal documentation. It turns a messy thread of calls and chat messages into one shared record that sales, engineering, and security can all use.

Common mistakes that waste time

Teams lose hours when they treat an assumption like a fact. A seller says a prospect will probably accept shared hosting, someone repeats it in Slack, and two weeks later the buyer asks for a dedicated deployment. Now the team debates who heard what instead of answering the request. In the log, each item should show whether it is confirmed, open, or guessed.

Another common problem is the hidden promise. It often starts with a casual line on a call: "we should be able to support that." If nobody records it in one visible place, it turns into a ghost commitment. By the time legal, security, or delivery reviews the deal, three versions of the same promise are floating around.

Splitting hosting and security requests from data flow notes creates a slower problem, but it hurts just as much. A prospect may ask where data sits, who can access it, whether logs contain customer content, and which systems receive exports. If those answers live across email, a spreadsheet, and meeting notes, people miss how one answer changes the others.

Old assumptions also linger longer than they should. Enterprise deal documentation changes fast when scope moves. A buyer might begin with a small pilot in one region, then ask for stricter retention rules or a private network connection. If nobody updates the earlier entry, the next reply uses stale information and resets the conversation.

The last mistake is simple: teams reply without naming an owner. "Need to confirm encryption limits" is not enough. Someone must own the follow-up, with a date and a next action. Without that, the same question bounces between sales, product, and engineering until the buyer asks again.

A short cleanup habit prevents most of this. Mark every item as confirmed, open, or guessed. Keep hosting, security, and data flow details in one place. Replace old assumptions when scope changes. Assign one owner to each unanswered point.

This is where the sales engineering handoff often breaks. The prospect thinks the company has one clear view of the deal. Inside the team, five people may be working from five different versions. A clean log fixes that faster than another meeting.

A quick check before every reply

A fast reply can create a week of cleanup. When a prospect sends another hosting or security question, pause for five minutes and read the latest notes first. If your answer drifts from the log, the deal splits into two versions: the one sales remembers and the one engineering can actually support.

Use the architecture assumptions log as a pre-send filter.

Confirm the newest hosting ask. A prospect may start with shared cloud, then ask for single-tenant hosting, a private VPC, or a specific region after one security call. Your reply should match the latest request, not the first one.

Check every non-standard promise. If someone said "we can support that," the note should include who said it and when. Names and dates stop loose comments from turning into fake commitments.

Read the data flow notes as if you joined the deal today. Can you explain what enters the system, where it is stored, what leaves it, and which systems touch it? If not, the notes are too thin.

Leave blanks where you still do not know the answer. Teams lose time when they patch missing facts with guesses and then defend those guesses later.

Match the reply to current engineering reality. If the team supports SSO only through one provider today, say that. If data retention is configurable only within a certain range, say that too.

This habit matters most when the deal has many voices. A salesperson may remember the prospect's first ask, a security lead may remember the strictest version, and engineering may remember only what it tested. The log gives everyone one shared version.

A simple test works well: hand the notes to a teammate who was not on the last call. If they can explain the expected data flow and the open limits without asking for help, your reply will probably stay consistent. If they cannot, add the missing detail before you send anything. One careful message now is cheaper than walking back a promise later.

Next steps for a team that wants less rework

Most teams do not need another system. They need one shared habit. Pick a single architecture assumptions log template and use it for every large prospect, even when the deal looks simple at first.

A plain document, spreadsheet, or internal form is enough if everyone uses the same fields. Once the format stays fixed, people stop rewriting the same answers about hosting, security limits, procurement rules, and data flow questions.

Keep the rollout simple. Choose one template and make it the default for enterprise deal documentation. Review it during every handoff from sales to technical staff. Check it again during solution review and once more before final approval. Keep the owner list short so updates happen fast and nobody waits for five people to agree.

That short owner list matters more than most teams expect. If sales, one technical lead, and one decision maker can update the record, the log stays current. If ten people can edit it, nobody feels responsible and the notes drift out of date.

The review rhythm should stay boring. That is a good thing. When a prospect asks for single-tenant hosting on Monday, raises a data residency concern on Wednesday, and adds custom security wording on Friday, the team should add those changes to the same record instead of starting a fresh thread each time.

This is where the architecture assumptions log starts paying for itself. It reduces repeat calls, cuts conflicting promises, and gives leadership a clean view of what the team actually agreed to.

Some teams can set this up in a week. Others benefit from an outside review, especially when enterprise requests pile up faster than the team can sort them. Oleg Sotnikov at oleg.is works as a Fractional CTO and startup advisor, and this kind of process cleanup fits naturally into that role. A fresh technical read can often spot vague promises and missing ownership before they slow a deal down.

Done well, this is a small discipline that saves hours on every serious deal.