CRM for Technology

What selling technology actually looks like

A software company's enquiry is rarely a phone call. It is a trial account created at 23:10 by someone with a company e-mail address who has also signed up to two competitors, a "book a demo" form filled in from a comparison article, or a message from a partner who met a prospect at an event. The person is technical enough to evaluate alone and busy enough to forget by Thursday. Whoever replies first with something useful — a working answer, a demo slot, a relevant example — gets the second conversation; the others get a trial that quietly expires.

The evidence on speed is old and blunt: the Harvard Business Review study of 2,241 companies found that responding within an hour made a lead nearly seven times as likely to be qualified as waiting even one hour more, and that the average response time was 42 hours. Technology companies are not slower than average; they are simply the ones where the founder is still doing sales between two deploys.

The second shape is the second sale. In a subscription or maintenance business, winning the deal is the start of the revenue, not the end. The customer who opened four tickets in the first month and got three of them answered late does not renew, and no pipeline report will show why, because the pipeline stopped watching at "won". Support and sales need to be on one record.

The pipeline we recommend starting from

Every stage is something that verifiably happened. "Interested" and "warm" are not stages; a trial created and a demo attended are.

For an IT services firm or integrator, the shape is the same with two differences: "scoping call" replaces "demo", and "proposal sent" carries a project estimate rather than a subscription price. Give product sales and services sales separate pipelines if you do both; Starter includes two pipelines, Growth five, Business ten.

Fields worth having on a technology lead

The lead-detail layout is configurable per role, so a sales rep sees value and trial fields, a support agent sees the technical contact and open tickets, and neither scrolls through forty inputs. Products carry their own custom fields too — plan tier, billing period, included seats — so a proposal is built from the catalogue rather than typed.

Trials, demos and the idle-trial problem

A trial that nobody from your side has touched by day three is, statistically, already lost. The lead webhook accepts a plain HTTP request from your own application, so a new trial account creates a lead the moment it is registered, with the plan, the sign-up source and the campaign fields attached. From there the work is scheduling, not remembering.

1. Day 0 — owner and first touchChannel distribution assigns the lead in turn; an automation sends the first message in the lead's language and creates a "call within 4 working hours" task.
2. Day 3 — the check-inA date-based automation on the trial-start field opens a task for the owner: has the trial done anything? The answer is a note and a stage move, not a feeling.
3. Demo — booked from the threadAn appointment with date, presenter and prospect; reminders go out by WhatsApp, SMS or e-mail; the outcome marks attended or no-show and moves the stage.
4. Day 12 — the expiry warningTwo days before trial end, a task and a message; a trial that expires without a conversation goes to Lost with the reason "no contact", which is a reason you can fix.

The response-time report measures the first reply in working minutes according to the shift calendar, so the 23:10 sign-up answered at 09:05 counts as five minutes, not ten hours, and the rep who consistently answers in forty is visible next to the one who answers in four.

Tickets: support as retention

The ticketing module is your customers' support desk inside the CRM: a customer raises a ticket by e-mail or through the form, or your team opens one from a WhatsApp conversation, and it lives on the same customer record as the deal that won them. Tickets have a status, a priority, an assignee and a message thread; assignment sends a notification; and a manager sees the queue by person and by age.

Three things make it work for a technology company rather than merely exist:

One record, both histories

The account manager opening a renewal conversation sees the twelve tickets from last quarter before the customer mentions them. The support agent sees the plan, the seats and who sold it.

Routing by rule, not by shouting

An automation assigns tickets by product, by customer tier or in turn across the support team, and re-notifies the assignee when a ticket sits unanswered beyond a time you set.

Ticket load as a sales signal

A pivot report of tickets by customer by month, next to deal value, is the churn early-warning a subscription business needs and rarely has.

It is worth being precise about what this is not: there are no contractual SLA timers or breach escalation chains. There are priorities, ages, assignment rules and reports, which is what most teams under fifty people actually use.

Automations that pay for themselves

Automations are rules with a trigger and one or more actions. Stage-level rules fire when a lead enters a stage; system-wide rules watch dates, idle time and incoming messages. The catalogue includes assigning an owner, sending a message or e-mail, creating a task, changing a field, adding a tag and moving a stage, and every run is logged with its outcome.

Sales, support, engineering: who sees what?

Roles decide which modules a person may use and what they may do in them — view, create, edit, delete, export — per entity. Data scope decides whose records they see: their own, their department's, or everyone's. Departments form an org chart; a manager sees what their department sees.

Sales rep

Own leads and deals plus unassigned; view and edit, no delete, no export; sees prices and own commission, not others'.

Sales lead

Department scope over sales; reassigns, exports, sees pipeline and response-time reports.

Support agent

Tickets and the customer records behind them; the inbox; no pipeline, no finance.

Engineer

Tickets assigned to them, read-only on the customer; nothing else. Most engineers want exactly this.

Founder / administrator

Everything, including finance, the activity log and settings.

The activity log records who viewed, changed, reassigned or exported which record — which is the answer when a customer asks who had access to their data, and a reasonable thing to have before a security questionnaire asks.

A week in a twelve-person software company

1. Monday — the weekend's sign-upsAlready assigned by distribution; each rep calls through their list from the softphone, sets seats and current tool, moves the stage.
2. Tuesday–Thursday — demosBooked from the thread, reminded automatically, marked attended; proposals built from the product catalogue and sent the same day.
3. Every day — the ticket queueRouted in turn, oldest first; an engineer picks up the two escalated ones; the customer sees replies on the thread they started.
4. Friday — the idle listProposals with no movement in ten days, surfaced by the automation; one call each, one honest lost reason where it applies.
5. Month end — the two reportsPipeline by stage and source; tickets by customer by month. Both on one screen, both exportable.

IT services and integrators: projects after the deal

An integrator or IT services firm sells a project, not a plan. The pipeline ends at "won", and the work begins: a task list with owners and dates, milestones, hours and costs. On the Business plan a won deal can open a project with its tasks, and the deal's income and expenses show its profitability — the estimate against what it actually cost in people and licences.

• Recurring tasks cover maintenance contracts: a monthly patch window, a quarterly review, a yearly licence renewal, each generating its own task on schedule.
• Products with cost prices cover resold licences and hardware; when the deal is won the cost is booked automatically and the margin on the resale is visible.
• Tickets under a contract stay on the customer record, so the account manager sees the support load when the renewal conversation comes.

Numbers a founder or sales lead should watch

• First-response time in working minutes, by rep — the number that predicts demos more than any other.
• Sign-up → demo rate and demo → proposal rate, by source — which campaigns produce buyers, not just accounts.
• Days in "Proposal sent" — the leak; if it grows, someone is not following up.
• Won deals and monthly value by rep by month — with the funnel behind them.
• Tickets per customer per month, and ticket age by assignee — the retention signal, next to the revenue it protects.
• Lost reasons by product — the product roadmap's cheapest input.

All of these come from the pivot report builder on Growth and above: rows, columns, a measure and a filter, saved and exported to CSV.

What this is not

This is not an engineering issue tracker: there are no sprints, repositories, releases or integrations with development tools. Tickets are customer conversations with a status and an owner; the bug behind a ticket belongs in your engineering tool, and the ticket carries its reference as a field.

It is not a subscription billing engine: it records deal value, income, expenses and commissions, but it does not charge cards, generate recurring invoices or handle dunning. And automated daily backups of your workspace are not currently part of the service; export what you must retain.

When it stops working

Which plan fits?

A two-founder startup doing its own sales runs on Starter. A company with a support team, more than a handful of trials a week and engineers who should see only tickets lands on Growth — for ticketing, automations and roles more than anything else. Services firms that need projects and margin per engagement go to Business. See the pricing page, and the ticketing and automation pages for the two modules that carry the load.