Why I Ask for Access Before I Send a Proposal

Why do I ask for access before sending a proposal?

Because a fixed-fee proposal is only honest if I have seen what I am quoting for. Before I price a website or automation project, I ask for read-only access to the site, the CRM, and any existing automations. A short look inside the real systems protects both sides from surprises.

I build websites and the automations behind them for lead generation. Almost every project touches something that already exists: a Webflow site, a HubSpot portal, a set of Zaps, an Airtable base. What lives inside those systems decides how long the work takes.

Across 100+ projects for 25+ clients over 6+ years, one lesson keeps repeating: the description of a system is never the system. Asking for access is not about distrust. It is about quoting a real number for real work.

What is wrong with quoting from a discovery call alone?

A discovery call tells me what the client wants. It rarely tells me what they have. People describe their systems the way they remember them, not the way they are. The gap between the description and the reality is where scope creep, missed deadlines, and awkward change requests come from.

This is not anyone's fault. A founder who set up their CRM two years ago cannot remember every workflow. A marketing lead may not know that a contractor added custom code to the site. A team may not realize three different forms feed the same list. These details only show up when someone looks.

If I quote without looking, I have two bad options. I can pad the price to cover unknowns, which is unfair to the client. Or I can quote tight and hope, which is unfair to me and usually ends in a tense conversation halfway through.

What kind of access do I ask for?

I ask for the lightest access that lets me see the structure. For a website, that is usually a guest or editor seat on the project. For a CRM or automations, a read-only user or a short screen share. I never need billing or personal passwords.

Read-only matters. At the proposal stage, I should not be able to change anything, and the client should feel completely safe granting access. If a tool does not offer read-only roles, a recorded screen share works fine. The goal is to see, not to touch.

I also tell the client exactly what I will look at and how long I will spend. I keep the review short. That keeps the request reasonable and shows I respect their time and their data.

What do I actually look for?

I look for the things that change the size of the job. On a website, that means how the CMS is structured, how much custom code exists, and how many templates and page types there are. In a CRM, property clutter and duplicates. In automations, what they write to and whether anyone monitors them.

Each finding moves the estimate. A clean CMS with clear collections might cut a migration in half. A portal with hundreds of unused properties adds cleanup time that the client probably did not expect. An automation that writes directly to deal stages with no error handling is a risk I need to flag, whether or not it is in scope.

I write down what I find in plain language and include it in the proposal. That alone builds trust. The client sees that I looked, that I understood, and that the price reflects their actual setup. My notes on what I check before taking over a Webflow site go deeper on the website side.

Why does this matter for fixed-fee pricing?

Fixed fees only work when the scope is clear. I price most projects at a fixed fee, usually between $1,000 and $10,000. A fixed fee shifts the risk of overruns onto me. Seeing the systems first is how I take on that risk responsibly, instead of guessing and hoping the guess holds.

Clients like fixed fees because they know what they will pay. I like them because they reward doing the work well rather than slowly. But both benefits disappear if the scope was wrong from the start. Access before the proposal is what makes the fixed number trustworthy.

I explain my reasoning on pricing in more depth in why I charge fixed fees, not hourly. The short version: a fixed fee is a promise, and I only make promises I can keep.

What if a client says no to sharing access?

Then I offer a short paid discovery step, or I quote with clearly written assumptions. Some companies have strict security rules, and that is fine. In that case, the proposal lists every assumption I made, and anything outside those assumptions becomes a change request. Clarity replaces visibility.

A paid discovery step works well for larger or riskier projects. The client pays a small fixed amount, I do a proper review under whatever access rules they need, and the result is a detailed scope they own, whether or not they hire me for the build.

Written assumptions work for smaller projects. "This quote assumes fewer than five CMS collections and no custom code" is a sentence that saves arguments later. If the assumption turns out wrong, both sides know exactly why the scope changed.

Does asking for access scare clients away?

Rarely, and when it does, it is useful information. Most clients appreciate that I want to understand their setup before naming a price. It signals care. A client who refuses all visibility and also wants a tight fixed quote is asking me to carry unknown risk for free, and that tells me something about how the project would go.

I frame the request carefully. I explain that it helps me give an accurate fixed price instead of a padded one. I make it easy, with clear instructions and read-only roles. And I promise to remove my access the moment the review is done if the project does not go ahead.

Saying no to a bad-fit project is part of running a healthy practice. A project that starts with hidden scope often ends with a strained relationship, no matter how good the work is.

What do clients get out of it?

Clients get a proposal that reflects their real systems, a price that will not jump halfway through, and a written summary of what I found, which is often useful on its own. Even if they choose someone else, they leave with a clearer picture of their setup than they had before.

I have come to see that summary as part of the value. Many teams have never had anyone look across their site, CRM, and automations at once. Seeing the connections, and the risks, helps them make better decisions regardless of who does the work.

It also sets the tone for the project. If the proposal is grounded in what I actually saw, the kickoff starts from shared understanding rather than assumptions. For how I turn that into a written scope, see what I put in a fixed-fee proposal. Access also changes the format of the proposal itself, which is why I prefer a recorded walkthrough to a proposal deck.

What should you do next?

If you are hiring someone for a website or automation project, offer read-only access before asking for a fixed quote. You will get a more accurate price and a clearer scope. If you are a freelancer, try asking for access on your next proposal and see how much more confident your number becomes.

Either way, treat the proposal stage as a chance to see reality, not just describe wishes. A quote built on what actually exists is the best protection both sides have against a painful project.

If you are planning a website or automation project and want a fixed-fee proposal based on what you actually have, reach out. I will take a careful look and give you an honest number. Let's chat.