Loss Reasons

Losing is part of the game; losing WITHOUT knowing why wastes the lesson. When marking an opportunity as lost, the salesperson picks a reason from this catalog.

Few and mutually exclusive (6–10): price, competitor, timing, no budget, no fit, no response. An "other" bucket that's too big = a bad catalog.

In the CRM Dashboard (losses by reason). A clear pattern = a clear action: losing on price → revisit the pricing; on timing → a follow-up cadence.

The catalog only works when it's lean: few reasons, each pointing to a different decision — price, competitor, timing, scope. When the list grows too much, the salesperson picks any one just to close the screen, records scatter into similar categories, and the dashboard analysis turns into noise. The registration is deliberately simple (description and active): if you feel a need for more detail, its place is in the opportunity's notes, not a new reason in the catalog.

When you save a view with the Views button, it stores four things: the search text, the applied filters, which columns appear (and in what order) and which column the list is sorted by. Applying the view restores everything at once — including resetting the sort and the page you were on, so the result is exactly what the view describes. Views saved before this version remain valid: whatever they didn't store simply doesn't change when applied.

Nas fichas, sair de um campo já dispara a conferência do que dá para conferir na hora: campo obrigatório deixado em branco e e-mail mal formado. O aviso aparece embaixo do campo e desaparece quando você começa a corrigir. Campo numérico não precisa de aviso: ele simplesmente não aceita letra enquanto você digita. Isso é conforto, não a validação final: ao salvar, o sistema confere tudo de novo do lado do servidor.

You can: the description is editable and the reason can be deactivated at any time. Just notice the effect: the analyses group losses by the reason's record, so renaming it also changes the label on old losses — good for fixing a confusing name, bad if the new text changes the meaning (then the history starts saying something else). In that case, deactivate the old reason and create a new one: the history preserves the original reading and the next losses already use the right one.

Open the record and look at the Timeline on the right: it shows each change as "from one value to another", with the person and the date. When there are many changes, use the two filters at the top of the timeline — one by field, the other by person. The search runs in the database, so old changes show up just the same. You can also ask Tenkai: "who changed contract 482?".