A single Zoho One tenant that captures leads from each of your websites, works them through a pipeline built for that specific business, turns them into projects and work orders, and ends in a Zoho Books invoice and a correctly-printed form — with adding business #4 being a day of configuration, not a second implementation.
Before any architecture: here is your requirement in my words. If any of this is wrong, it is much cheaper to correct now than in week four.
Not three separate systems that happen to be from the same vendor. One tenant where Contractors Only, Carrentals Only and Car Pawns each behave like their own business — and a fourth can be added without a rebuild.
A form on the business's own website creates a lead. The lead is worked hot / medium / cold / dead with automated messaging. When it's real, it becomes a project with its own working area, work orders and people.
The project produces an invoice to the customer in Zoho Books, payments out to the contractors who did the work, and printed forms — on your dot-matrix printer, on non-standard stock, populated automatically.
"EVERYTHING MUST BE SCALABLE SO WE CAN ADD MORE BUSINESSES." That sentence is the real specification. It rules out the fastest way to build this — three separate configurations bolted together — because that approach makes business #4 cost what business #1 cost. Every decision in this document is made against the question: what does this cost us at ten businesses?
| Your requirement | How this plan meets it | Built with |
|---|---|---|
| 1a. Add more businesses easily | Each business is a Layout, not a system. New business = clone a layout, clone a blueprint, add a profile. A written runbook, ~1 day, by an admin. | Native |
| 1b. Users restricted to certain businesses | Layout permissions per profile — a Car Pawns clerk cannot see or create Contractors records at all. Not a filter they can remove; a permission. | Native |
| 2a. Hot / medium / cold / dead + auto call, text, email | Lead Status field driving workflow rules. Each state has its own automation; every message lands on the lead's timeline. | Native + SMS provider |
| 2b. Any state to any other state | Deliberately a free picklist rather than a locked process — so a dead lead can go straight back to hot with one click. | Native |
| 2e / 2f. Embeddable forms with multiple images and files | Zoho Forms per business, embedded on each site, multi-file and image upload, conditional questions — landing straight in the right Lead layout. | Native |
| 3a / 3b. States depend on the business, modular to change | One Blueprint per business, edited in a drag-and-drop designer. Changing a stage is a five-minute admin job, not a change request. | Native |
| 3d / 3e. Work orders, multiple people per project | Work Orders as a child module of Projects; Crews with a named Team Leader; contractors from a Vendors register. | Native |
| 4a. Invoices + populate non-standard PDFs | Zoho Books for invoicing; Zoho Writer merge templates at exact custom page size for the pre-printed forms, with a physical alignment calibration pass. | Native + custom |
| 4b. All forms in one place | A Print Centre tab on every project: every form that business uses, listed, one click to generate populated and filed. | Custom |
| 5b. Contacts on multiple projects across multiple businesses | A many-to-many link between Contacts and Projects. One contractor, one record, visible on every job across every business. | Native |
| 5c. Work organised in teams with a leader | A Crews module: crew name, Team Leader, members, trade, and which businesses they work for. | Native |
| 5d / 5e. Avoid too much custom; document what is custom | Four named custom components, no more — each with written documentation. Everything else is configuration Zoho maintains for you. | Native |
| 6a / 6b / 6f. Cleaner, non-technical UI and dashboards | Canvas redesigns the record pages, Kiosk turns long forms into short guided steps, and dashboards give you the KPI row from your screenshot. | Native |
| 6e. Usable from a phone | Zoho CRM mobile app on iOS and Android. Canvas layouts carry over; site photos go from phone camera straight onto the work order. | Native |
Four stages, left to right: capture a lead from the right website, work it in the CRM, deliver it as a project with work orders and crews, then bill it and print the paperwork. Everything below sits in one Zoho One tenant with one shared contact database — which is what makes a contractor reusable across all three businesses.
There are three ways to build multi-business in Zoho. Two of them look fine at three businesses and fall apart at ten. This is the one decision worth getting right before anything is built, so here is the reasoning in full.
| Approach | One contractor usable across businesses |
Group-wide reporting |
Cost of business #4 | Why it does or doesn't work |
|---|---|---|---|---|
| A separate Zoho org per business Three tenants, three logins |
✗ No | ✗ No | A full re-implementation, plus another set of user licences | Every contractor, customer and vehicle is duplicated by hand in each org. There is no group view without exporting to a spreadsheet. This is the approach that quietly costs the most. |
| One org, one shared layout A "Business" dropdown on every record |
✓ Yes | ✓ Yes | Cheap — add a dropdown value | But every business's fields live on every record. By business #5 a lead form carries 150+ fields, most irrelevant to whoever is looking at it, and "restrict users to a business" becomes a filter someone can switch off. |
| One org, one layout per business Recommended |
✓ Yes | ✓ Yes | Roughly a day, configuration only, no developer | Each business gets its own fields, its own stages and its own forms inside a shared module — and layout permissions mean a user without access to a layout cannot see it, create in it, or report on it at all. |
Access is set in two independent layers, so you can be precise: layout permissions decide which businesses a person can work in at all, and roles plus data-sharing rules decide which records inside those businesses they can open. A sample of how that lands:
| Profile | Contractors Only | Carrentals Only | Car Pawns | Record-level scope |
|---|---|---|---|---|
| Group Administrator | ✓ | ✓ | ✓ | Everything, plus setup rights |
| Contractors Manager | ✓ | ✗ | ✗ | All Contractors records |
| Contractors Coordinator | ✓ | ✗ | ✗ | Only leads and projects assigned to them |
| Rentals Clerk | ✗ | ✓ | ✗ | All Carrentals records |
| Pawns Clerk | ✗ | ✗ | ✓ | All Car Pawns records |
| Bookkeeper | ✓ | ✓ | ✓ | Read-only in CRM; full rights in Books |
This is the difference between a system you can grow into and one you outgrow. On the recommended model, businesses #4 through #10 are configuration — a day each, done in-house. On either alternative they are projects, and you would be paying for each one.
Your brief asks for something subtle: four temperature buckets with automation on each, and the freedom to move a lead from any bucket to any other. Those two pull against each other, and the way you resolve it decides whether the system feels helpful or obstructive.
Zoho has a feature called Blueprint that locks a record into a defined sequence — you can only move forward, and only if you fill in what the stage demands. It is the right tool for the project pipelines later in this document. It is the wrong tool for lead temperature, because your requirement 2b says a lead must be able to go from any state to any other. So temperature stays a plain field that anyone can change in one click, and the intelligence lives in the automation that fires on arrival at each state. You get the behaviour without the cage.
Automated texting is the one part of your brief that needs something outside Zoho, so it is worth being straight about it up front rather than at the end of the build.
| What you want | How it's delivered | Included in Zoho One? | Running cost |
|---|---|---|---|
| Automated SMS on state change | CRM notification SMS wired to a provider (Twilio, Kaleyra or similar) | Automation yes, gateway no | Per message, paid to the provider |
| A two-way texting inbox like the conversations screen you shared | A marketplace SMS extension that adds a conversation panel to the record | ✗ Separate subscription | Monthly per user, plus messages |
| Click-to-call, auto call logging, recordings | PhoneBridge connected to a telephony provider (Zoho Voice, Twilio, RingCentral) | Connector yes, minutes no | Per minute or per seat |
| Email sequences and nurture | CRM workflows plus Zoho Campaigns | ✓ Included | None |
| Live chat on all three sites | Zoho SalesIQ, one installation per site, chats land on the lead | ✓ Included | None |
The messaging interface in your document is from a purpose-built automotive product, and nothing in Zoho looks exactly like it. What Zoho gives you natively is every text, call recording and email on one timeline on the lead — the same information, in a list rather than a chat bubble. I would build that first, because it is included, and add the paid two-way inbox extension only if your team still misses it after a few weeks of use. That way you find out whether you are paying a monthly fee for a real gap or for a habit.
"The states for this will depend on the individual business" and "should be modular so changes can easily be made to the states" — that is exactly what Zoho's Blueprint designer does. Each business gets its own stage flow, drawn on a canvas, and changing it later is an admin editing a diagram, not a developer editing code.
A Blueprint can refuse to let a project move to "Crew Assigned" until a crew, a leader and dates are filled in. That is how the data stays clean without anyone policing it.
Each transition can be restricted to a role — a coordinator can advance a job to In Progress, but only a manager can mark it Approved.
Open the designer, drag in a stage, set what it requires, save. Existing projects keep working. This is the "modular" part of your requirement 3b, and it needs no developer.
Contracting and rental both fit the standard job-and-invoice pattern. Lending does not: it has a principal, a rate, a repayment schedule, a running balance, collateral you are holding, and a default path that ends in selling someone's car. This plan builds all of that as tracking — the loan record, the schedule, the balance, the branch above — and it will run your operation well. What it is not is a regulated-lending compliance system. Licensing, disclosure wording, title handling and repossession notices vary by state and should be confirmed with your counsel; I will build to whatever rules they give me, but I am not the source of them.
Contractors Only is the business you called most important, and it is also the one with the hardest data shape: one job, many trades, many contractors, organised into crews with a leader — and those same contractors turning up on other jobs in other businesses.
| Module | Origin | Per-business behaviour | What it holds |
|---|---|---|---|
| Leads | Standard | One layout each | Everything the website form captured, including images and files, plus temperature, source and owner. |
| Accounts / Contacts | Standard | Shared | Customers and people. One record each, visible from every business they touch. |
| Vendors | Standard, extended | Shared | The contractor register: trades, day rates, ratings, documents, and licence & insurance expiry dates that trigger alerts before a crew is dispatched uncovered. |
| Crews | Custom module | Shared, tagged by trade | Crew name, Team Leader, members, availability, which businesses they work for. Directly answers requirement 5c. |
| Projects | Custom module | One layout + one blueprint each | The working area. Customer, site, budget, stage, dates, everything related hanging off it. |
| Work Orders | Custom module | One layout each | Child of Projects. Trade, scope, assigned crew, agreed cost, schedule, status, photos. |
| Vehicles / Assets | Custom module | Used by Rentals & Pawns | VIN, make, model, mileage, condition, current status, valuation history, title documents. |
| Loans | Custom module | Car Pawns only | Principal, rate, term, schedule, running balance, collateral link, default state. |
Zoho has a dedicated Field Service Management product with dispatch boards and a technician app, and for Contractors Only on its own it would be a good fit. I am not proposing it here, for one reason: it is a separately licensed product with its own single-business structure, so adopting it would split your operation into "the FSM business" and "the CRM businesses" — the exact fragmentation this whole plan exists to avoid. Work orders in CRM cover what your brief describes. If Contractors Only later grows into daily multi-crew dispatch scheduling, FSM is the right conversation to have then, and nothing here blocks it.
Your brief says "at the end, we will need to pay people of course". That sentence is doing a lot of work — it means the system has to handle money going out as well as money coming in, and that is what turns a CRM into something you can actually run a contracting business on.
A Zoho Books organisation is one set of books: its own chart of accounts, its own tax registration, its own invoice numbering. The native CRM-to-Books connector links one CRM organisation to one Books organisation. So the number of Books organisations you need is not a preference — it follows from how many legal entities you actually trade through, and it changes the build.
One Books organisation. Recommended where it applies, and it is the cheaper and simpler build by a clear margin.
Three Books organisations. Unavoidable if the businesses file separately — and then honesty matters more than elegance.
| In Zoho CRM | Direction | In Zoho Books | Note |
|---|---|---|---|
| Accounts & Contacts | → | Customers | Created on first invoice, kept in step after that |
| Vendors | → | Vendors | So contractor payouts reference the same record you vetted |
| Products / service items | ⇄ | Items | One price list, both sides |
| Estimate on a project | → | Estimate → Invoice | Line items carry across; no retyping |
| Project / Work Order reference | → | Invoice & bill custom field | This is what makes per-job margin possible |
| Payment status on the project | ← | Payments & credit notes | Your coordinators see "paid" without a Books login |
| Business name | → | Branch + reporting tag | Drives the invoice template, numbering and the per-business P&L |
This is the part of your brief most people will skim past, and it is the part most likely to go wrong. A pre-printed form at 8.5 × 11.69 inches, going through a dot-matrix printer onto multi-part stock, has to land within about a millimetre or the whole page is scrap. So it gets designed as its own component, with its own calibration step in the plan.
"Dot matrix printer" plus "non-standard size PDF" can mean two genuinely different technical jobs. They cost about the same to build, but they are built differently, and guessing wrong wastes a week. One sample of your blank stock and one correctly filled specimen settles it in five minutes.
The printer receives a complete page image, boxes and all, and prints the whole thing onto blank stock. This is the more common case.
The form is already printed on multi-part paper. The printer must strike only the values, in exactly the right boxes. Precision is unforgiving.
For every form to be automated: one blank, one filled in correctly by hand, and the printer's make and model. From those three things I can tell you which case you are in, confirm the page geometry, and give you a per-form estimate before building any of them. Sending them early costs you nothing and removes the biggest unknown in this project.
| Form type | Where it's raised from | Populated from | Ends up |
|---|---|---|---|
| Vehicle purchase order Pawns | The loan or project record | Vehicle, owner, valuation, amounts | Printed and signed; PDF filed on the record |
| Rental agreement Rentals | The rental project at Agreement stage | Customer, licence, vehicle, dates, rates, deposit | Zoho Sign, or printed at the counter |
| Condition / inspection report Rentals Pawns | Handover and return | Vehicle, odometer, fuel, damage notes, photos | Signed by both parties, filed to the project |
| Work order sheet Contractors | Each work order | Site, scope, crew, leader, dates, agreed cost | Printed for the crew to take to site |
| Customer invoice All | Zoho Books | Job line items and taxes | Emailed or printed on that brand's template |
| Remittance advice All | Zoho Books vendor payment | Bills settled in the run | Sent to the contractor when they're paid |
You asked whether the interface can be cleaner than stock Zoho. It can — and importantly, it can be done with Zoho's own design tools rather than hacks, so nothing breaks when Zoho updates and nothing depends on me being available to fix it.
A drag-and-drop designer for the record page itself. The five things a coordinator actually needs get made large and put at the top; the other forty fields move out of the way. Each business can carry its own colour.
Turns a long form into a short guided sequence. "Log a walk-in" becomes three screens with four questions each instead of one page with forty boxes. This is the direct answer to "usable by anyone without technical ability".
The KPI row you shared is standard dashboard components — counters, funnels and trend arrows. One dashboard per business, plus a group view for you.
The Zoho CRM app on iOS and Android, carrying the same Canvas layouts. A crew leader photographs the finished work and it lands on the work order before they leave the site.
Roughly what your Contractors Only dashboard would look like on day one — every number clicks through to the underlying list.
Yes — but only with Zoho's supported tools, never by fighting the platform. Canvas, Kiosk and dashboards are how Zoho intends interfaces to be reshaped, and they survive updates. What I would not do at this stage is build a fully bespoke front end over the top: it looks impressive in a demo, doubles the cost, and every future change has to come back through me. You would lose exactly the self-sufficiency the rest of this plan is designed to give you.
Each phase ends at a gate: something working that you sit in front of and accept before the next phase starts. That is deliberate — it means you are never more than three weeks from seeing real progress, and never asked to pay for a phase you haven't seen.
Two weeks of included support follow Gate 3 — for questions, small adjustments and anything that surfaces in real use. Beyond that I am happy to continue on a retainer or ad-hoc basis, but the plan is deliberately built so that you don't need me: adding businesses, changing pipeline stages and adjusting dashboards are all documented as things your own admin does.
One fixed price for the scope in this document, released across the three acceptance gates. No deposit line — the first milestone is the deposit, and it is earned against something you have seen working.
Because that is where the work is. Phase 1 carries the data model, the permission architecture and the business-template pattern — the decisions everything else is built on top of, and the ones that are genuinely expensive to change later. Phases 2 and 3 largely assemble on that foundation: cloning the template, connecting Books, building templates against forms you supply. The money follows the build density rather than the calendar, which is why 45/30/25 rather than an even third each.
Path B on Zoho Books. Three separate legal entities means a custom bridge for two of the three organisations — roughly a week of additional work. I would rather tell you that now than discover it in week five.
Forms in Case 2. If your forms are pre-printed carbon stock needing character-level positioning rather than a full-page PDF, the per-form effort goes up. Send me the samples and I will confirm before you commit — at no cost, and either way it does not change Phases 1 and 2.
Around five years building on Zoho full time, for clients across more than ten countries, and I am Zoho Creator Certified. Day to day that means Zoho CRM administration, Zoho Books and CRM-to-Books integration, Zoho Creator, Zoho Flow, Deluge scripting, Writer merge templates and REST API work.
More relevant to you specifically: multi-entity CRM builds and CRM-to-Books integrations are ordinary work for me, not new territory. The layout-per-business pattern in section 3 is a pattern I have used before, not something invented for this proposal — which is why I can commit to a seven-week timeline with a straight face.
Six to seven weeks, in three phases, with an acceptance gate at the end of each — set out in full in section 10.
The part worth noticing: Contractors Only is usable at the end of week three, not at the end of week seven. Since you named it the most important business, the plan front-loads it deliberately. The timeline assumes you can give me system access in week one and roughly two hours a week of review time; if either slips, the schedule slips with it, and I will tell you as it happens rather than at the end.
Deliberately little — roughly 85% of this is native configuration. Your requirement 5d asks for exactly this, and I agree with it: custom code is a liability you carry forever, while configuration is something Zoho maintains for you and your own admin can change.
Custom work is confined to four named places, and nothing else:
Every one of those four gets written documentation explaining what it does, where it lives and how to change it — your requirement 5d-i.
Five, and they are set out in full below — the number of Books organisations, the real nature of your forms, the fact that Car Pawns is lending rather than sales, the running cost of two-way texting, and one question about whether a lead can produce more than one project. The first two are the ones I'd like answered before we start.
Less than you might expect, but the few things I do need matter. Full list in section 13 — the short version is: system access, a decision on legal entities, samples of your forms, and one named person per business who knows how that business actually works and can sign off a gate.
Yes — using Canvas, Kiosk and dashboards, which are Zoho's own tools for exactly this. Record pages get redesigned so the fields that matter are large and first; long forms become short guided steps; each business can carry its own colour; and the dashboard row from your document gets rebuilt as standard components. Section 9 shows roughly what that looks like.
What I will not do is build a bespoke front end over the top of Zoho. It demos well and then costs you twice: once to build, and again every time you want a change, because it can only come through me. Everything I am proposing survives Zoho's updates and stays editable by your own admin.
These are the questions I would ask on a first call. None of them is a reason not to build this — but each one is cheaper to answer now than to discover in week five.
This is the single biggest fork in the plan. One entity trading under three names means one set of books with branches and tags — simple, cheap, nothing custom. Three separate entities filing separately means three Books organisations, and the native connector only covers one of them.
Section 8 covers both cases. They look identical in a brief and are built quite differently, and the alignment tolerance on a dot-matrix printer punishes a wrong guess. This is the item most likely to cost time if we get it wrong.
I can build the loan record, the repayment schedule, the running balance, the collateral link and the default-to-repossession-to-resale path — that part is straightforward, and it is in this plan.
What I cannot supply is the regulatory layer around it: state licensing, required disclosure wording, how title must be held, what notices must be served before repossession and when.
Automated one-way SMS is included in the build; the conversation-style inbox from your screenshot needs a marketplace extension with a per-user monthly subscription on top of the message charges.
A technical question with a real operational answer behind it. A property owner might come in once and generate three separate jobs over two years. A rental customer might rent five times. If one lead maps to exactly one project, the model is simpler; if it can produce many, the customer relationship needs to sit above the project rather than beside it.
Roughly two hours a week of your time, plus these. Most of it is week one; the rest is turning up to the three gates.
Administrator access to the tenant, or a super-admin who can grant it. If you haven't bought Zoho One yet, tell me your user count first and I'll help you size it before you spend anything.
Whether the three businesses file separately. Needed before Phase 3, not before Phase 1 — so there is time, but it shouldn't be forgotten.
One blank and one filled-in copy of each form to automate, plus the printer make and model. The earlier these arrive, the earlier the biggest unknown in the project disappears.
Someone who actually knows how Contractors, Rentals and Pawns each run, can answer questions without escalating, and can accept a gate. It can be the same person for all three.
The fields you want on each of the three sites. I'll draft a first version from your brief — you correct it rather than starting from a blank page.
Whoever maintains the three sites. I supply the embed code and the specification; they paste it in. Ten minutes of their time per site.
Customers, contractors, vehicles — a spreadsheet is fine, however messy. Cleaning and importing it is part of Phase 1.
Which provider you want to use. I'll recommend one based on your countries and volume; you own the account so the numbers and message history stay yours.
Your brief says the system must be usable by anyone without technical ability and scalable to ten businesses. Both of those are decided by how well I understand how you actually work — not by how much I build. Time spent with the person who runs Contractors Only in week one is worth more to this project than any feature in it.