Brand plan · v2 · name locked · three routes
This plan audits what the product wears today, names the trust it actually trades in, and hands you three complete identities — each with its own mark, type, colour and the buyer it is built to convert. The name is settled: Vanisree, set by the client. What is still open is which argument the identity should make.
01 · Diagnosis
The Flutter shell ships Flutter's own blue (#0175C2 in sales_tracker/web/manifest.json). The screen specification asks for “Enterprise Gateway” — #2563EB with an orange #F97316 CTA and Fira Code/Fira Sans (docs/screens-by-role.md). The desktop dashboard binds violet, navy and rose, annotated in code as “Literal brand values from vanisreeeducation.com” (web/src/app/globals.css). Three systems, one product.
sales_tracker/assets/logo/app_logo.svg measures 247,056 bytes and carries embedded C2PA provenance reading “compositeWithTrainedAlgorithmicMedia”. It cannot be recoloured, has no clear-space rule, no minimum size, no monochrome cut, and no relationship to a wordmark. It is a picture of a logo.
The PWA manifest says "name": "Vanisree" with "description": "A new Flutter project." That string is what a device, an installer and a store listing will read back. The product's first impression is boilerplate.
Documents call it “Sales Tracker”; the app calls itself “Vanisree”. Resolved: the name is Vanisree, set by the client, so the naming question is closed and out of scope for this plan. What remains is the more expensive half — the mark, the type and the colour that make the name mean something. Note the loose end: “Sales Tracker” still appears in the documents a buyer reads, and every one of those strings now has to be retired.
Manrope ships inside the app (sales_tracker/assets/fonts/), Geist and Quicksand drive the dashboard, and Fira Code/Fira Sans are specified for screens. Nothing here is a decision; all of it is leftovers from whatever was scaffolded first.
This product's real claim is that a visit is verifiable: GPS at punch-in and punch-out, an odometer reading plus photo, visit start and end coordinates, offline capture, and a live activity that punches in from the lock screen. The identity says none of it. The in-repo tagline — “Track your team, close more deals” — sells the category, not the difference.
The screen inventory counts 57 screens: 26 exist, 31 are missing, 1 is partial. That is the argument for doing this now — settle the tokens once and thirty-one future screens are born branded, instead of arriving in a fourth palette.
02 · The product, in its own words
Punch-in and punch-out record coordinates; punch-out also demands an odometer reading and a photo of it. Selfie capture is optional by design so a bad camera never blocks the close of day.
A manager assigns the circle of outlets; the rep executes it, records the outcome, books the order and raises the lead. Follow-ups, adhoc visits, missed punch-out recovery and travel claims sit in the same day.
Everything lands in the on-device store first and syncs later, so a visit in a dead zone is still a visit. That single property is why the data can be trusted at all.
screens in the inventory — 26 built, 31 still to come.
tables in the encrypted on-device database that makes offline work real.
desktop roles already served: admin, zonal manager, manager, accountant.
declared app version — mature enough to stop looking like a prototype.
03 · Who has to believe you
| Role | What they are actually afraid of | What they must believe | What converts them |
|---|---|---|---|
| Field rep | Being blamed for a visit they did make. | This protects me as much as it checks me. | Two taps from the lock screen; nothing lost when the signal drops. |
| Manager | A team that looks compliant on paper only. | I can see the day while it is happening. | A live round with an exceptions queue, not a report at month end. |
| Zonal head | Numbers that arrive too late to act on. | I can change something before the month closes. | Zone rollups that open on what went wrong, not on totals. |
| Owner / MD | Paying for a team they cannot see. | I can trust the number without asking for it. | One reconciliation view where every figure links to its record. |
| Accountant | Claims that cannot be reconciled. | Every rupee has an attachment. | Odometer photo and GPS trail attached to the claim itself. |
04 · Positioning
For Indian distribution teams running twenty to five hundred people on the road, this is the field-force system where every visit, order and kilometre is verifiable at the moment it happens — on the phone already in the rep's pocket, with or without network. Attendance apps record that someone was present. This proves what the presence produced.
No number appears without its proof.
A figure on a dashboard opens the record it came from: the rep, the timestamp, the coordinates, the photo. Nothing is aggregated past the point where it can be traced back. This is not a UI nicety — it is the product's competitive position expressed as a rule, and it is the single thing competitors selling dashboards cannot copy without rebuilding their data model.
05 · Three complete routes
The name is fixed, so these are no longer three names to choose between. Each route is a different argument aimed at a different person in the room, drawn as a complete identity on the same locked wordmark: mark geometry, type system, colour physics, voice and product application.
The record is the argument: evidence-grade, cool, exact. Built to convert the owner and the accountant, who buy proof rather than enthusiasm.
Open route 01The day’s round is the argument: warm, human, rep-first. Built for adoption, because a system reps refuse to open proves nothing at all.
Open route 02The closed book is the argument: paper-led, two-colour, reconciling. Built to convert the MD who still runs the business on a bahi-khata.
Open route 0306 · The name
Two items sit under the locked name. The Devanagari companion cut in route 02 is drawn as वनिश्री — that spelling is ours, not the client's, and must be confirmed by their office before any script version is produced. And whether “Vanisree” is registered in class 9 or 42, and whether the parent's existing mark already governs the typography, is a question for their counsel. Neither blocks the choice between the three routes. Both block production.
07 · From looking to buying
| Stage | What the buyer is doing | What the identity must supply |
|---|---|---|
| 1 · First look | Comparing you against two attendance apps in a store listing. | One specific, falsifiable sentence. Not “streamline your sales” but “every attendance record carries GPS and an odometer photo”. |
| 2 · The demo | Waiting to see whether this is another dashboard that lies to them. | A demo that opens on an exception — a visit with no proof — and resolves it on screen. The identity sets that expectation before the demo starts. |
| 3 · The pilot | Running one team for a month and reporting upward. | Report templates (the PDF and Excel generators already exist in the backend) that carry the brand, because the buyer forwards your artefact to their own boss. |
| 4 · Roll-out | Extending to every zone. | Tokens shipped into the app before the remaining 31 screens are written, so nothing looks half-branded at scale. |
| 5 · Renewal | Defending the spend. | Language the buyer now uses in their own meetings: proven, verified, reconciled. You own the vocabulary of the outcome. |
| 6 · Referral | Showing the app to a peer in the same trade association. | An app icon that survives contact with a real home screen, and a name the peer can repeat from memory after hearing it once. |
08 · Non-negotiables
Whichever route you pick, these hold. They are written as constraints so the thirty-one unbuilt screens cannot drift.
09 · Rollout
10 · Open questions
A field-force product is bought on trust and kept on habit. Name the trust, then make the habit easy.
Each sheet is drawn in its own system — mark, colour, type, product screens and the buyer it is aimed at.
Open the three identity sheets