The problem
Most companies do not plan to run quotes out of a spreadsheet. It starts as a temporary aid next to the CRM, then quietly becomes the real system. The tab with the current template is known by whoever set it up. Everyone else copies it, renames it and hopes.
That pattern fails in ways that cost money. A rep edits a row while a colleague has the file open, and one of them loses the change. A price is typed by hand from a list that was updated last month. A discount gets applied twice because the formula was copied down one cell too far. The customer receives a quote with a stale price or the wrong product description, and the correction call is awkward.
The deeper problem is that nothing in the file knows what a quote is. A row is just cells. There is no record of who changed a unit price from 400 to 350, no link between a quote and the list it came from, and no way to answer a simple question: how many quotes went out last week above the discount limit. Answers get assembled by hand, late, by someone who resists doing it.
Approvals suffer most. A rep emails a PDF to a manager, the manager replies ok, and the actual approval lives in a mailbox. When finance later asks who approved a large discount, the trail runs through three inboxes and a phone call.
What a good solution looks like
A good quote app separates two things the spreadsheet smashes together: what you sell and what you offered a specific customer.
Start with a product catalog. Each item needs a SKU, a description, a unit such as each, hour or license, a unit price, a currency, a cost figure and an effective date range. Prices change, so keep old rows and close them with an end date instead of overwriting. A quote then points at a catalog item, and each line keeps a copy of the price and description it used at the moment it was created. That copy matters. Editing the catalog next month must not silently rewrite a quote the customer already accepted.
A quote record needs a small set of fields: customer, contact, quote number, owner, status, valid until date, currency, payment terms and a notes field. Status should be a short fixed list such as draft, in review, sent, accepted, declined and expired. Line items hold the catalog reference, quantity, unit price snapshot, a discount and a computed line total. Totals, tax and rounding are calculated on the server, never in the browser alone.
Then the parts that make it usable. Role based permissions, so a rep can create and send quotes but only a manager can approve a discount above the limit. A change history that records every edit with the user and a timestamp. A PDF that matches the template your customers already expect, generated from stored data rather than retyped. And exports, because finance will want a CSV and your BI tool will want a feed. Keep it small. You are replacing a quote file, not buying a configure price quote platform.
How to build it
Take the current spreadsheet apart before writing code. List every column and mark which ones are typed by hand, which are formulas and which are copied from somewhere else. That list is your data model. You will usually find three or four columns that always come from a lookup and two that are free text where they should not be.
Build in this order. First the catalog table with price history and an import from your existing price sheet. Second the quote header and line items, with server side totals and a locked price snapshot. Third the PDF, because until a rep can send a document that looks right, nobody will trust the app. Fourth the approval step, with a threshold per role and a simple queue of quotes waiting on a decision. Fifth sign in through your identity provider and the role mapping. Last the exports and the search.
Watch the numbers. Rounding, tax and currency conversion are where quote apps quietly disagree with finance. Decide the rule once, write it down, and put it in one function that every total passes through. Test it with a credit note, a zero quantity line and a quote that spans two currencies if you sell in more than one.
Roll it out to two or three reps for a week while the old file stays read only. Ask them to rebuild quotes they already sent and compare the output line by line. Fix the gaps, then switch off editing on the shared file and move the archive somewhere clearly labeled as historical. A runbook of six or seven pages is enough: how to add a product, how to change a price, how to approve, how to reissue a quote and who to call.
Risks and how to manage them
The most common failure is the file that never dies. Someone keeps a personal copy just in case, updates it, and now you have two price lists. Make the app the only place a quote number can be issued, and set the old file to view only. Check after a month whether anyone still creates quote documents outside the app.
Price and tax drift comes second. Give one named person ownership of the catalog, and make a price change an event with an effective date rather than an edit. If a price is wrong, close the old row and add a new one. That way a quote sent in March still makes sense in July.
Scope is the third risk. Requests to add CRM fields, commission splits or order fulfillment arrive in week two. Write them down and defer them. A quote app that ships beats a half finished order management system.
Do not skip the boring controls. Back up the database on a schedule you have actually restored from. Keep the history table append only so it cannot be edited from the interface. Restrict exports to roles that need customer data. And log sign in failures, because a quote list is a map of your pipeline.
How to measure success
Pick five numbers and look at them monthly. Time from request to sent quote, measured per rep. Number of quotes that needed a correction after sending. Count of discounts above the approval limit and how many had a recorded approval. Number of quotes still created outside the app. Time to add a new product to the catalog.
The approval metric is the sharpest one. In a spreadsheet it is unmeasurable, which is exactly why problems hide there. In the app it becomes a query.
Ask finance one question after the first month: how much retyping did you do from quote PDFs into the accounting system? That number falling is the clearest sign the change stuck. Watch the tail too. A rep who sends two quotes a month will not notice the app unless the second one takes noticeably less time than the first.
If you would rather not build this in house, options range from a spreadsheet template you adapt with a contractor to a packaged sales tool you configure. Cloudverg's Internal tool sprint is one option: a fixed price of $16,500 for one workflow built end to end in four weeks, with sign in through your identity provider, roles, change history, import of your current data, CSV and finance exports, a training session and a written runbook. Weigh that against your own build time and another quarter of quotes that need correcting.
Frequently asked questions
How do I stop salespeople from editing prices in a quote app?
Do not give the quote screen a free price field. Line items pull the unit price from the catalog by SKU, and any override needs a role permission plus a written reason, which is saved to the change history.
Can I import my existing quote spreadsheet?
Yes for the catalog, and that is where to start. Clean the price sheet first so there is one row per SKU, one price per currency and an effective date on each row. Old quotes are usually better archived than imported, because their formulas rarely map cleanly.
What is the difference between a quote app and a CPQ platform?
A quote app stores products, builds line items, applies discounts within limits and produces a PDF with an approval trail. A configure price quote platform adds configuration rules, bundles and subscription billing. Most small and mid sized teams need the first.