I’m trying to find a good CRM for my type of business. I own a service-based B2B company where I’m a vendor for apartment communities, so a lot of my sales/outreach is done in person.

Right now I’m using Notion, basically set up like Excel/Google Sheets. It works, but it’s almost entirely manual. It’s just me and my secretary using it.

I do a lot of follow-ups through in-person visits, phone calls, and emails. I understand I’ll probably still have to manually enter some information, but I’d like a CRM that can automate or assist with things like follow-up reminders, tracking contacts, sales stages, notes, tasks, etc., rather than having everything written down and managed manually.

What CRM would you recommend for a small B2B service business with a heavy emphasis on in-person sales and follow-up?

When looking at a pipeline, the deal stage doesn't always tell you enough.

Two deals can both be in the same stage, but one might be moving normally while the other has been sitting there for too long.

So I added a simple Deal Health check based on the expected date.

The idea is to make it easier to spot:

→ Deals that are on track

→ Deals getting close to their expected date

→ Deals that are late

→ Deals that are already done

It's a small feature, but I think these little visual cues make a deal tracker much easier to scan

curious what's one thing you think a deal tracker should flag automatically?

Its free if anyone wants it

Trabalho com CRM e vejo esse erro em praticamente todo report que passa numa

reunião. Vale compartilhar porque é simples de reconhecer depois que alguém aponta.

O caso típico: base de 200 mil, 180 mil têm e-mail válido e recebem a campanha, 20 mil ficam de fora porque o cadastro está incompleto. No fim do período: recebeu a campanha: 1.620 compras em 180.000 = 0,90% não recebeu: 60 compras em 20.000 = 0,30% 

"A campanha triplicou a conversão." Ninguém questiona, porque o número é grande.

O problema é que quem não recebeu, não recebeu por um motivo, e esse motivo tem

relação direta com propensão de compra. Cadastro incompleto anda junto com menor

vínculo com a marca. Esses dois grupos já eram diferentes antes de qualquer envio.

Quando se sorteia 10% da base ANTES do disparo, o grupo de fora converte a 0,75%,

porque é feito da mesma gente. Aí o lift real aparece: 20%, não 200%. A campanha

funcionou, mas o report exagerou dez vezes, e foi sobre esse número inflado que a

empresa decidiu aumentar o investimento.

O teste de dez segundos que resolve a maioria dos casos: "existe alguma razão para

esse grupo comprar mais ou menos que o outro, independentemente da campanha?" Se

a resposta for sim, não é grupo de controle. Se você precisar pensar muito para

responder, também não é.

Os falsos controles mais comuns, todos parecem legítimos: quem não tem e-mail

válido, quem deu opt-out, quem não abriu a mensagem, quem ficou fora do segmento,

quem teve falha de entrega, e o mesmo período do ano anterior.

This is a monthly megathread where you can all clamour for CRM attention without being banned for spamming this forum. Share your CRM, or consultancy service to your hearts content, (just keep your dignity!) The idea here is to keep the rest of r_crm less spammy, so don't be surprised if your regurgitated chatGPT output and link don't ever get approved elsewhere on this sub.

-----

When replying, please use the following format:

Put [ASK] at the start of your comment if you're asking/looking for something.

... we'll assume the rest are people recommending without being asked :D

As always, please disclose your relation to what you're posting.

I built a Notion CRM for small agencies and consultants, with separate databases for companies, contacts, and deals.

I decided to make the Deal Tracker part available for free on its own.

It lets you manage individual deals, track their stage and value, connect them to a company/contact, set follow-up dates and reminders, and keep Won/Lost deals organized.

I also included an example version so you can explore the workflow without changing your own data.

If you want to see how the full CRM connects everything together, I've included a link to it as well.

I’m 24 and graduated in 2025 with a Psychology degree. I’m currently trying to transition into marketing, and I’ve become particularly interested in CRM, lifecycle marketing, email marketing, and marketing automation.
What attracts me to this area is the combination of psychology/customer behaviour, communication, technology, analytics, experimentation, and understanding what actually drives customers to take action.
I’ve been looking at entry-level and junior roles, and I’ve noticed that many of the positions I’m interested in seem to focus heavily on practical skills and experience rather than requiring a specific marketing degree.
I’m considering spending the next 6 months seriously building my skills before trying to make the transition.
My current learning plan includes:
CRM and lifecycle marketing fundamentals
Email marketing strategy
Customer segmentation
Customer journeys
Marketing automation
HubSpot and/or Klaviyo
Email copywriting
Excel/Google Sheets
Basic SQL
Marketing analytics
A/B testing and experimentation
Campaign reporting and performance analysis
My goal isn’t to become an expert in six months. I want to become competent enough to understand how the work is actually done, build a few relevant projects, and eventually be competitive for a junior CRM/lifecycle/email marketing role.
For people currently working in CRM, lifecycle, retention, or email marketing:
If you were starting over with a Psychology degree and no professional marketing experience, what would you prioritize learning during your first 6 months?
Are there any skills/tools that you think aspiring CRM/lifecycle marketers spend too much time learning, or anything that beginners commonly overlook?
And realistically, how difficult is it to get that first CRM/lifecycle marketing job without a marketing degree?
I’d really appreciate advice from people who actually work in this area.

Most field-service CRMs treat every technician like a permanent software user.

I never liked that model.

A tech may only need access to one job, one customer, for one period of time. Why should that require giving them a permanent account with ongoing access to the company's CRM?

So with Chameleon-CRM, I built it differently.

When a job is dispatched, the technician can receive a secure Magic Link and access PIN by email.

That gives them access to their technician workspace where they can see what they actually need for the job — customer/job information, dispatch details, photos, notes, status controls, and the tools needed to complete the work.

They don't need a traditional CRM username/password.

And the important part:

When the job is over, the business can revoke that access.

The workflow becomes:

Create job → Dispatch tech → Send temporary access → Tech completes work → Revoke access

The technician's ability to work in the field doesn't mean they need permanent access to the company's entire business system.

I also deliberately separated this from employee/time-clock access. If someone is actually an employee who needs payroll and time tracking, they're managed accordingly. Being dispatched to a job doesn't automatically make someone a permanent internal CRM user.

This has turned into one of my favorite parts of building Chameleon-CRM because it changed the question from:

"What role should this user have?"

to:

"What does this person need access to right now?"

That's a much more interesting way to think about fieldservice software.

I'm curious what other people running service businesses think about this approach.

Would you rather give every field tech a permanent CRM account, or give them access only when there's actually work assigned to them?

I am a big believer of Apollo for prospecting, sequencing and dialing (anything outbound). I hate that it does not have a CRM integration with Attio. Like how do people keep a tab of Apollo activity in Attio (like dials, prospecting etc.). This might be a deal breaker for me to migrate from Attio over to Hubspot or something.

I’ve been building something that sits between a CRM and a social app.

Traditional CRMs are built around contacts, accounts, deals and activity.

Social networks are built around people, interaction and connection.

I’m exploring what happens when you combine the two. A CRM × Social layer focused on the actual relationships behind your network and represented to you in a real time visual map with an intelligence layer

I’ve built the MVP and I’m looking for a few people who use CRMs to test it and tell me where the idea falls apart.

I’m particularly interested in whether this feels like a genuinely useful new direction for CRM, or just an interesting idea on paper.

What do you feel your current CRM is missing when it comes to managing real relationships?

If you’re interested in testing the MVP, drop a comment or DM me - I’d love your feedback and I’ll send you a voucher for coffee ☕️

I've noticed that entering information into a CRM is often the easy part.

The more interesting part is what happens afterwards.

Does your CRM simply store the information, or have you built processes around it so that the right action happens at the right stage?

I'm curious how different teams handle that transition from recording information to actually doing something with it.

I've been thinking about how much CRM functionality a small business actually needs.

For many freelancers, consultants and small teams, the main questions after sending an important email are pretty simple: Was it opened? When was it opened? And when should I follow up?

That's one of the reasons I built OpenDot, a lightweight Gmail extension focused on email open tracking and real-time notifications without requiring users to move their workflow into a full CRM.

I'm curious how people here see this: at what point does a business actually need a full CRM instead of a lightweight email tracking tool?

Our marketing tech stack has grown significantly over the last two years. We are running separate platforms for user behavioral analytics, outbound email sequences, form enrichment and webinar hosting. all attempting to sync back into our primary CRM. The main issue we are facing is data inconsistency and duplicate records. A lead fills out a form with one email address, gets enriched via a third-party tool, attends a webinar under an alternate email address and suddenly we have three different contact records in our CRM with fragmented engagement history. Our sales reps are complaining that lead scoring is unreliable because activity data lives in different tool silos or takes hours to sync over. For those running a modern marketing stack alongside a central CRM, how are you handling identity resolution and deduplication?

I’m looking for a few companies to pilot Quantara Flow AI with us.

Quantara Flow AI is an AI-powered customer operations platform designed to help teams manage customer cases while understanding what is actually happening across their operation.

It brings together:

• Customer case management and Customer 360
• AI-assisted responses and case summaries
• SLA tracking and intelligent escalation
• Automated QA across customer interactions
• Sentiment, intent and emerging trend detection
• Root Cause Analysis to identify why customers keep contacting you
• Knowledge management and AI-powered agent assistance
• Operational dashboards and real-time insights
• Workflow and case automation

The idea is simple:

Instead of managers spending hours reviewing tickets, conversations, reports and spreadsheets to understand what is going wrong, Quantara Flow AI continuously turns customer interactions into operational intelligence.

The Pilot

I’m looking for a small number of companies willing to use Quantara Flow AI in a real customer-service environment.

We will:

→ Configure the platform around your operation
→ Onboard your team
→ Select specific processes/use cases to improve
→ Run the pilot using real operational scenarios
→ Measure the impact before and after
→ Work closely with your team throughout the pilot

In exchange, I’m looking for detailed product feedback and, if we demonstrate measurable value, permission to build an approved case study around the results.

There is no expectation to publish sensitive customer information or internal data.

For me, this isn't about creating a perfect demo.

I want to see Quantara Flow AI operating against real cases, real workloads and real operational problems.

If you manage Customer Experience, Customer Service, Contact Center, Operations or Support and would be interested in becoming one of our pilot customers, comment below or send me a DM.

quantaraflow.com

To change or to not change the due dates of activities, that is the question.

The most often debated topic when working with activities or tasks in CRMs like Pipedrive is whether you should change the due dates of overdue activities.

I will present what I think is the best thing to do with overdue tasks or activities.

Problem

On any given day, a salesperson has to do a number of tasks. Life happens and they may not be able to get through their tasks for the day, even if the number of tasks is manageable. Moreover, more often than not, salespeople are burdened with more tasks than they can handle. So any task they are not able to complete on a given day becomes an overdue task the next day.

The argument in favor of changing due dates is that people do not want to deal with the burden of having ‘overdue tasks’.

The biggest problem with moving due dates is that you lose context of how overdue you’re. On any given day, it is impossible to tell apart a task that is actually due for today from a task that was rescheduled for today. So there is a very high chance that activities that have been overdue for long will continue to be overdue because you will always have more activities than you can reasonably complete in a given day.

Secondly, it gives you a false impression that you’re on top of your sales pipeline and that things are fine when they’re actually not. The workload in the upcoming week far outweighs the workload in the weeks after.

So, my advice is to not move due dates. When you start your day, focus on everything that’s due for today. Once done, move to the Overdue list, and get cracking. Over time, you will get rid of overdues, but if you keep moving due dates of tasks, you will have to do this due date moving activity every day, which is a complete waste of time.

Scenarios where you need to change due dates

Apologies if this heading got you excited.

But I am going to rule out every case where you want to change the due date of the activity or, in simple words, move the activity.

Moving an activity without talking to a lead

Don’t do that.

If you do that, you’re asking the prospect to move according to your pace, where in fact, you should be responding to the prospect’s needs by moving along their pace.

Moving an activity when your outreach attempt was not successful

If your outreach attempt was unsuccessful, mark the activity as done, and schedule a new activity for a future date.

If you do that, you will get a clear idea of the number of attempts you’ve had to make to finally get in touch with somebody. This information will be very useful when you try to model “what happens if our leads increase by 10%”.

If you don’t do that, you will lose sight of how hard you’ve tried to reach out to somebody, and if you have tried enough. At some point, you have to give up on trying to reach out to a prospect, right?

Moving an activity with an incorrect due date

This one’s easy.

Just be careful when creating activities. Make it a habit to check these details when creating activities to avoid wasted time and effort, and frustration.

Be patient and diligent.

Moving an activity to follow up in the future

Again, don’t do that.

Just mark the previous activity as done, jot down your notes, and schedule the next activity. Let the logged data tell you and your team how many activities are required to get prospects into a particular stage of the pipeline. This will help them plan staffing requirements too.

Conclusion

My advice was always going to be ‘don’t do it’.

I just wanted to rule out every case one would think of to justify moving activities.

So, don’t do it.

It’s better to have overdue tasks than to move due dates of activities or tasks.

I’m starting a CRM and sales operations service and I’m looking for one small business using HubSpot to work with as a pilot.

I’d review and tidy up your sales pipeline things like stale deals, missing information, unclear ownership and missed follow-ups.

I’m doing the first one for free because I want to build a proper case study from real work. I’d just ask for honest feedback and, if you’re happy with the result, a short testimonial.

If your HubSpot pipeline has gotten a bit messy and you’d like some help, feel free to reply.

Short answer: document the business problem, the current workflow, the required outcomes, and the exceptions that matter. You do not need a finished technical specification, but you should give prospective implementers enough detail to distinguish a real solution from a generic software pitch.

A useful preparation packet can be only a few pages. Include these six sections:

1. The decision you are trying to make

State whether you are evaluating a new CRM, improving an existing system, automating a handoff, replacing spreadsheets, or integrating two platforms. Name the decision deadline and who will approve the work.

1. The current workflow

Describe where the process starts, each major step, who owns it, which systems are used, and where work commonly waits or gets re-entered. A simple numbered list is often more useful than polished diagrams. Include one representative example using fictional or redacted data.

1. The required outcome

Define what must be better in observable terms. Examples include one accountable owner per request, fewer duplicate records, visible failure queues, consistent approval history, or a reliable way to report status. Avoid prescribing a feature before explaining the operational result it must support.

1. Users, roles, and permissions

List the people who create, review, approve, assign, complete, and report on the work. Note what each role must see or change. This prevents an estimate built around administrator access while overlooking daily users.

1. Data and integrations

Identify the important records, their current sources, required fields, approximate data condition, and any systems that must exchange information. For every integration, describe the direction of data, trigger, timing expectation, and which system should be authoritative.

1. Exceptions and constraints

Document the cases that do not follow the happy path: duplicates, missing information, cancellations, reassignment, offline work, failed payments, unavailable APIs, or records that require manual review. Also disclose security requirements, retention rules, budget boundaries, internal technical capacity, and dates that cannot move.

Ask every proposer to separate assumptions, standard configuration, custom work, integrations, migration, testing, training, ongoing ownership, and out-of-scope items. Require them to explain how failures are detected and recovered, not only how the normal path works.

You do not need to choose the software first. In fact, documenting the workflow before selecting a platform makes it easier to compare options against the same needs and exposes where process decisions—not technology—are still unresolved.

Which part of your current workflow would be hardest to explain accurately to an implementation partner?

Treat CRM migration as a business-decision project, not a bulk copy. The safest goal is not “move every record.” It is “move the records people need, in a structure they understand, with enough traceability to trust the new system.”

Start with these six decisions:

1. Define what must move. Separate active customers, open opportunities, current contacts, required historical records, and data that can remain in a read-only archive. Keeping everything often preserves duplicates, obsolete fields, and unclear ownership.
2. Assign an owner to each data set. Sales should decide what makes an opportunity active. Finance should confirm which account identifiers matter. Operations should define the customer and job details needed after handoff. A technical team can map fields, but it should not invent business definitions.
3. Create a field-level mapping. For every source field, document the destination field, data type, allowed values, transformation rule, and what happens when the value is blank or invalid. Mark fields that will be retired. This catches ambiguity before import day.
4. Clean by rule, not by intuition. Agree on repeatable rules for duplicate contacts, inconsistent company names, stale statuses, malformed email addresses, and records without owners. Preserve original IDs so questionable records can be traced back to the source.
5. Rehearse with a representative sample. Include ordinary records and difficult cases: multiple contacts at one company, closed and reopened opportunities, missing values, unusually long notes, and records connected to several objects. Have actual users check search, ownership, timelines, reports, and downstream handoffs.
6. Reconcile after each test import. Compare source and destination counts by record type and status, then investigate differences. Spot-check key fields and relationships. “The import finished” is not the same as “the migration is correct.”

Before the final cutover, write down the freeze window, final export time, import sequence, validation owners, rollback threshold, and how changes made during the freeze will be handled. After launch, keep the old system read-only for an agreed period instead of immediately deleting access.

One practical test: ask a salesperson to find an active account, understand its recent history, identify the next action, and hand it to operations. If that flow is confusing in the migrated sample, more mapping work is needed before go-live.

This community is support by Hexagon IT Solutions

Which part of CRM migration has created the most uncertainty for your team: deciding what to keep, cleaning it, mapping it, or validating the result?

Chameleon-CRM has grown to the point where calling it a CRM doesnt really explain what it is anymore.

The original idea was simple: why should a business need a CRM, scheduling platform, dispatch system, invoicing software, payment system, employee management platform, inventory software, marketing tools, customer portal, field-service app, and a pile of integrations just to run one company?

So we started building Chameleon as an Adaptive Business Operating System instead.

Chameleon handles customers, leads, jobs, tickets, appointments, estimates, invoices, receipts, expenses, taxes, vendors, purchase orders, inventory, employees, payroll, time tracking, subscriptions, memberships, gift cards, marketing, payments, automations, customer communication, field technicians, and more from one connected system.

But the biggest difference is that Chameleon is completely adaptive.

When we say adaptive, we don't mean that you can change the color of the dashboard or rearrange a couple widgets.

We mean Chameleon is designed around the idea that the software should adapt to the business instead of forcing the business to adapt to the software.

An HVAC contractor doesn't operate like an auto repair shop. An auto repair shop doesn't operate like a salon. A landscaping company doesn't operate like an MSP. A roofer doesn't operate like a veterinarian. Even two HVAC companies may have completely different workflows depending on their size, services, employees, dispatch model, and how they get paid.

Traditional CRMs usually start with one workflow and expect everyone to fit inside it. Chameleon takes the opposite approach.

Your industry, workflow, enabled features, team structure, permissions, terminology, and the way you actually use the system determine what your Chameleon environment becomes.

That means Chameleon can function as an HVAC CRM, plumbing CRM, electrical CRM, landscaping CRM, roofing CRM, auto repair system, detailing CRM, janitorial platform, pest-control CRM, salon management system, MSP platform, veterinary business system, or something entirely different without us maintaining a completely separate application for every industry.

And adaptation doesn't stop at signup.

A one-person business might primarily use customers, scheduling, estimates, invoices and payments. As that company grows and hires its first technician, Chameleon can become a dispatch system. Add office employees and it becomes a multi-user operational platform. Add inventory and purchasing and it starts managing that side of the company. Add recurring services and memberships and it begins managing recurring revenue.

The same Chameleon workspace can evolve with the company.

That's the philosophy behind the name Chameleon.

Dispatching is one of the largest parts of the system. A company can create a job, assign a technician, schedule it and dispatch it directly from Chameleon.

Road technicians don't need normal Chameleon accounts or passwords. They can receive secure magic-link access to the work they've actually been assigned. That gives them a purpose-built field interface without exposing the company's entire CRM.

From the field, technicians can access job and customer information, view instructions, upload job photos, update work, communicate with dispatch and use the tools required to complete the job.

Chameleon also supports live field location functionality. Dispatch can see technician locations while they're working, and Premium businesses can enable breadcrumb location history when they need additional visibility into field operations.

Internal employees are handled differently. Owners can create authorized users such as managers, dispatchers, supervisors, salespeople, accounting personnel and support staff and control what those users are allowed to access.

And an authorized Chameleon user isn't automatically considered a clocked-in employee. If that person also belongs on payroll, they're created in the payroll system and punch in and out like any other employee. System access and employment records remain separate.

Scheduling is integrated directly with the rest of the platform. Businesses can create appointments, connect them with customers and jobs, manage their calendar and require deposits when necessary.

If you receive an appointment that you're uncomfortable confirming without money down, you can require a deposit and have the customer directed through the payment process before that appointment is confirmed.

Chameleon also handles estimates, invoices, receipts, expenses and taxes. Instead of financial documents existing in an unrelated program, they're connected to the customer and the work that generated them.

For larger jobs, Project Milestones allow businesses to break a project into stages and collect incremental payments instead of financing an entire project themselves until the final invoice.

Recurring revenue is built into the platform through subscriptions and memberships. HVAC maintenance agreements, landscaping plans, cleaning contracts, managed IT services, pest-control programs and other recurring services can live alongside ordinary one-time jobs.

Inventory and purchasing are part of the system as well. Businesses can manage products, inventory, vendors and purchase orders while keeping those operations connected to the rest of the company.

Chameleon includes employee and payroll functionality, time logs and punch-in capabilities so businesses can manage the people doing the work alongside the work itself.

There's a customer-facing side too. Customer portal functionality allows businesses to give their customers access to the information intended for them without exposing the internal CRM.

Chameleon includes communication tools and a Unified Inbox so conversations aren't completely disconnected from the customers and jobs they're about.

We've also built marketing capabilities directly into the platform, including AI-assisted marketing tools. Smart Invoices and other AI functionality are designed around reducing repetitive administrative work rather than adding an AI button just because AI is popular.

Automation is another major part of where Chameleon is headed. If the system already understands the customer, appointment, job, invoice, technician and payment, those pieces shouldn't require humans to constantly move information between different applications.

There's also the System Hub, which gives owners centralized control over authorized users, permissions, configuration and other administrative parts of their workspace.

Payments are integrated into Chameleon as well. Businesses on the Free plan currently have a 2.9% Chameleon platform fee, while Premium reduces that to 0.8%. Premium is currently $79/month or $499/year, meaning businesses processing enough payments may be able to justify Premium from the reduced platform fee alone.

Then there's Desktop Mode, which is our attempt to rethink what business software itself can look like.

Instead of everything being permanently trapped inside the traditional sidebar-and-dashboard CRM design, Chameleon can provide an operating-system-like environment with applications, windows, shortcuts, wallpapers, pop-out functionality and workflows designed with multi-monitor businesses in mind.

Chameleon also supports different saved working environments because an owner, dispatcher, accountant, manager and marketing employee shouldn't necessarily stare at the same workspace all day.

That's really where the adaptive concept comes together.

Different industries. Different employees. Different workflows. Different stages of growth. Same underlying platform.

A two-person HVAC startup should not have to operate Chameleon the same way as a 30-person service company.

A dispatcher shouldn't have to use it like an accountant.

A road technician shouldn't have to use it like the owner.

And a landscaping company shouldn't have to pretend it's an HVAC company because that's how its software was originally designed.

The software changes around the business.

That's what we mean by Adaptive CRM.

The long-term goal isn't to build the biggest collection of features possible. It's to build a system where those features actually understand one another.

A lead becomes a customer. A customer books an appointment. An appointment becomes a job. A dispatcher assigns a technician. The technician performs the work. Photos and information come back from the field. The work generates an invoice. The customer pays. The payment becomes part of the business's financial picture. The relationship can become a membership or recurring service. Marketing can bring that customer back again.

One continuous system instead of ten applications passing data back and forth.

That's why we're increasingly hesitant to describe Chameleon as simply another CRM.

We're building toward something much larger:

An adaptive operating system for running a business.

And we're still building.

DaemonCore

This is a weekly post for you to let out about something which happened this week for you in CRM that mattered: features, client requests that were either great or awful this week, and just generally chat CRM / CRM consulting chatter.

No self promo, just a place to share tales from the front-line of CRM!