# ServeCommand Documentation — Complete Text

> Complete text of the public ServeCommand documentation.
> Index: https://www.servecommand.com/llms.txt

> For the complete documentation index, see [llms.txt](https://www.servecommand.com/llms.txt).

# Documentation

Understand the rules, customer terms, and connected workflows behind ServeCommand. A practical guide to putting your business decisions into the system.

Source: https://www.servecommand.com/docs

## A system shaped by your rules.

Get to know the building blocks, then follow the work from a pricing decision to a customer commitment.

## Start here

- [Understand the ServeCommand system](https://www.servecommand.com/docs/overview.md): How ServeCommand connects customer records, Site details, pricing rules, memberships, and invoice review for modern contractors and their teams.

## Business rules

- [Conditional pricing rules](https://www.servecommand.com/docs/conditional-pricing.md): Understand how Site details, location, fixed amounts, and formulas shape service pricing in ServeCommand, and how to review exceptions.
- [Owner tags and customer benefits](https://www.servecommand.com/docs/owner-tags.md): Use owner tags to carry percentage or fixed discounts across a customer's Sites while preserving saved benefit terms and agreed membership prices.
- [Review pricing differences before invoicing](https://www.servecommand.com/docs/invoice-review.md): Understand ServeCommand pricing checks, compare current and calculated rates, and distinguish deliberate exceptions from missing pricing inputs.

## Connected workflows

- [Connect memberships and campaigns](https://www.servecommand.com/docs/memberships-and-campaigns.md): Give customers a clear next step with property-specific membership offers, payment choices, and follow-up informed by existing work.

---

> For the complete documentation index, see [llms.txt](https://www.servecommand.com/llms.txt).

# Understand the ServeCommand system

How ServeCommand connects customer records, Site details, pricing rules, memberships, and invoice review for modern contractors and their teams.

Source: https://www.servecommand.com/docs/overview
Updated: 2026-10-06

ServeCommand is business software for modern contractors. It connects pricing rules, customer benefits, membership terms, job records, and billing review so the office, sales team, and field crew can work from the same customer and property context.

These guides explain how those parts fit together. Start with the policy you want your team to follow, then understand which part of the system carries it forward.

## Who is ServeCommand for?

ServeCommand is designed for businesses where work passes between people: an owner sets the standards, sales makes an agreement, technicians record what happened, and the office reviews the bill. It is especially relevant when repeat decisions about property pricing, customer benefits, or recurring work still depend on someone remembering the owner's intent.

The [irrigation business overview](https://www.servecommand.com/irrigation-business-software) shows those decisions in the context of zones, pump fees, memberships, and seasonal visits.

## Customers and Sites

A customer and a Site describe different things. The customer is the owner you do business with. A Site is the property where the work happens. One owner can have several Sites.

This distinction matters when you price work. The property's details can determine its service price, while the owner's customer benefits can apply across their Sites. A membership describes agreed services and terms for the covered property.

## Turn a decision into a repeatable rule

Use the right mechanism for the decision:

| Business decision | ServeCommand concept |
| --- | --- |
| A service should cost more when a Site meets certain conditions. | [Conditional pricing](https://www.servecommand.com/docs/conditional-pricing.md) |
| A preferred customer should receive a consistent benefit. | [Owner tags](https://www.servecommand.com/docs/owner-tags.md) |
| A price differs from the current calculation and needs attention. | [Invoice review](https://www.servecommand.com/docs/invoice-review.md) |
| A customer should receive a property-specific membership offer. | [Memberships and campaigns](https://www.servecommand.com/docs/memberships-and-campaigns.md) |

Rules calculate. Tags carry customer benefits. Memberships preserve a commitment. Review tools make exceptions visible so a person can decide what to do.

## Example: an irrigation season

Imagine an irrigation company preparing for spring. It records the details needed to price work at each Site, defines its service pricing, and prepares a seasonal membership offer. A customer can review the services and payment choices for their property.

When the team delivers the work, the agreed membership terms provide context for pricing. If a price differs from the expected calculation, review tools help the office understand whether it is an intended member rate or a difference to resolve.

This is an illustrative workflow, not a preconfigured package. Your services, Site data, rules, and membership terms determine the result.

## Start with one policy

Choose a decision your team currently has to ask you about. Write down the conditions, the intended outcome, and the exceptions. Use these guides to identify where that decision belongs before adding more rules.

## What should I bring to a demo?

Bring a service price list, a typical property with an exception, a membership offer if you use one, and the steps your office takes before sending a bill. Remove customer-identifying information from examples you share. Seeing your actual policy makes it easier to discuss fit than starting with a generic feature checklist.

Import scope, integrations, setup responsibilities, and available features need to be confirmed for your business. These guides do not promise a migration timeline or an autonomous agent workflow.

For a walkthrough with your own business in mind, [book a demo](https://www.servecommand.com/demo).

---

> For the complete documentation index, see [llms.txt](https://www.servecommand.com/llms.txt).

# Conditional pricing rules

Understand how Site details, location, fixed amounts, and formulas shape service pricing in ServeCommand, and how to review exceptions.

Source: https://www.servecommand.com/docs/conditional-pricing
Updated: 2026-09-30

Conditional pricing lets you define when a service price should change and how to calculate that change. Saved rules give the team a repeatable calculation for new work.

## Conditions describe when a rule applies

Service pricing conditions can use a Site's state, city, distance from the office, and structured Site data. Supported Site fields include numbers, yes/no values, and single-choice or multiple-choice values.

For irrigation work, a numeric Site field might describe the number of zones. A rule can use that field when it has been configured for the service category and the Site has a recorded value.

Office distance is straight-line distance. It is not a driving route or a travel-time estimate.

## Actions describe what happens to the price

A pricing action makes two choices:

| Choice | Meaning |
| --- | --- |
| Set to | Replace the running rate with the rule's amount or formula result. |
| Add | Add the rule's amount or formula result to the running rate. |
| A fixed amount | Use an amount defined in the rule. |
| A formula | Calculate an amount from numeric Site fields and arithmetic operations. |

The distinction between setting and adding matters. Setting defines a rate; adding builds on a rate. Choose the behavior that matches the policy you intend. Matching rules run in order, so a later Set to action can replace an earlier result.

## How do I price irrigation services by zone count?

Record the number of zones in a numeric Site field. Then choose the approach that matches your service policy: fixed prices for bands of zone counts, or a formula that calculates the rate from the number of zones. Zone count is a field your business configures, not an assumed value on every property.

Here is an illustrative winterization policy using bands. These are example rates, not market recommendations or a preconfigured ServeCommand price list.

| Site has | Pricing action | Service rate |
| --- | --- | --- |
| 1–4 zones | Set to a fixed amount | $100 |
| 5–8 zones | Set to a fixed amount | $140 |
| 9–12 zones | Set to a fixed amount | $180 |
| A pump requiring extra work | Add a fixed amount after the zone rule | +$35 |

With this policy, a six-zone property with a pump is $140 + $35 = **$175**. A property with more than 12 zones needs another band or an explicit review policy; the example does not cover it.

## Can I use a formula and a pump fee together?

Yes. A formula can calculate a rate using the configured numeric Site field, and a separate matching rule can add the pump fee. For example, **$60 + zones × $10**, followed by **+$35 when Pump is Yes**, produces $155 for six zones with a pump.

Use the formula or the bands according to your intended policy. Applying both would change the result. Put the pump addition after the rate-setting action: a later Set to action would replace the running total. A yes/no Site field can represent the pump condition when it is configured for the relevant service category.

## Check the policy before your team uses it

1. Confirm that zone count and pump details are recorded correctly for the Site.
2. Test the edges of each band, such as four and five zones.
3. Test a property with a pump, one without, and one outside your defined bands.
4. Check a property with missing details. Missing numeric formula inputs are treated as zero, so incomplete data can produce an unintended rate.
5. Review any saved Site-specific price or membership commitment before replacing it.

These are checks for configuring your policy, not a claim that every incomplete property is automatically blocked.

## Missing information needs review

A calculation is only as useful as its inputs. If a distance rule cannot be evaluated because the Site or office coordinates are unavailable, pricing review identifies that limitation and shows the available calculation separately.

A manual price or a saved Site-specific rule can also differ from the broader company calculation. Review the reason before changing a customer price. Agreed membership rates require their own context.

## Related guides

- [Owner tags and customer benefits](https://www.servecommand.com/docs/owner-tags.md)
- [Review pricing differences before invoicing](https://www.servecommand.com/docs/invoice-review.md)
- [Memberships and campaigns](https://www.servecommand.com/docs/memberships-and-campaigns.md)
- [ServeCommand for irrigation businesses](https://www.servecommand.com/irrigation-business-software)

---

> For the complete documentation index, see [llms.txt](https://www.servecommand.com/llms.txt).

# Owner tags and customer benefits

Use owner tags to carry percentage or fixed discounts across a customer's Sites while preserving saved benefit terms and agreed membership prices.

Source: https://www.servecommand.com/docs/owner-tags
Updated: 2026-09-30

Owner tags connect a customer label to a pricing benefit. A tag can carry a percentage or fixed discount into new estimates and work orders across that owner's Sites.

Here, owner means the customer who owns the property. It does not mean the owner of your contracting business.

## Define a reusable customer benefit

A tag has a name and a discount. Percentage discounts can also have a maximum discount amount. When automatic benefits overlap on eligible work, the best benefit applies. Manual price adjustments remain separate.

The saved tag name can appear as the discount label on customer documents. Choose a name that makes sense to the customer, such as a clearly described partner or preferred-customer benefit.

## Example: a customer with several properties

Suppose an irrigation company gives a preferred customer a consistent discount. That customer owns several Sites, each with a different system size and service price.

An owner tag carries the customer's benefit across new work at those Sites. The Site details still matter to the service calculation; the customer benefit is a separate part of the price.

For an illustrative 10% benefit, a $160 eligible service would receive a $16 discount, while a $220 eligible service at another Site would receive a $22 discount. The same customer policy follows the owner; the property's service calculation still determines the starting rate. Taxes, unrelated items, and other adjustments are outside this example.

Your business decides which customers qualify and the terms of the benefit.

## Should this be an owner tag or a Site pricing rule?

| The reason for the price | Where it belongs |
| --- | --- |
| More zones or a pump changes the work required at the property. | A service pricing condition using Site data. |
| A preferred customer receives a benefit across properties. | An owner tag with the agreed benefit. |
| A specific property has a negotiated service rate. | A saved Site price where supported. |
| A visit is included in an accepted membership. | The membership's saved service terms. |

Keep the reason attached to the right record. A label for a customer relationship should not replace the details needed to price the property.

## Saved terms are preserved

Editing a tag does not rewrite the benefits already saved for existing customers and documents. Those records keep their saved terms.

Archiving a tag prevents new assignments. Customers who already have it retain their saved benefits until the tag is removed from them. Removing an assignment stops future applications; it does not rewrite saved document discounts. Archiving a reusable tag is therefore different from ending a specific customer's benefit.

These distinctions help keep a settings change from silently changing what has already been given to a customer.

## Membership visits keep their agreed price

Work included in a membership keeps its agreed membership price. An owner-tag benefit does not become an additional discount on that covered visit. Extra work outside the membership can receive an eligible customer benefit.

When a price looks different from the usual service calculation, check whether it reflects a membership commitment or another saved benefit before treating it as an error.

## Related guides

- [Conditional pricing rules](https://www.servecommand.com/docs/conditional-pricing.md)
- [Review pricing differences before invoicing](https://www.servecommand.com/docs/invoice-review.md)
- [Memberships and campaigns](https://www.servecommand.com/docs/memberships-and-campaigns.md)
- [ServeCommand for irrigation businesses](https://www.servecommand.com/irrigation-business-software)

---

> For the complete documentation index, see [llms.txt](https://www.servecommand.com/llms.txt).

# Review pricing differences before invoicing

Understand ServeCommand pricing checks, compare current and calculated rates, and distinguish deliberate exceptions from missing pricing inputs.

Source: https://www.servecommand.com/docs/invoice-review
Updated: 2026-09-30

Pricing checks mark rates that need context. Invoice review summarizes those differences. In the work order, open a marked rate to compare the saved price with the current calculation and see the difference.

A pricing mark is a prompt to investigate. It does not automatically correct the price or prove that someone made a mistake.

## Understand the difference

Review the current price, calculated price, and the rule behind the calculation. A difference may come from a manual price, a Site-specific rule, an agreed membership benefit, or information that needs updating.

For supported service lines, ServeCommand can show that a rate was set manually when the saved pricing record identifies the change. A saved Site rule also has its own pricing context, so an intentional property-specific price can be distinguished from the broader company rule.

## Example: a winterization price needs attention

An irrigation team finishes a winterization visit. The recorded rate is below the price calculated from the current service rules.

The office checks the Site details and the reason for the rate. On supported editable lines, an office user can apply the current calculation. For services that support Site pricing, an intentional property price can be saved for future work at that Site.

For example, a saved rate of $140 could differ from a $175 calculation because the current rules include a $35 pump fee. Check whether the pump work was performed, whether the property details are correct, and whether the customer had an agreed rate. This is an illustrative review, not evidence of a real customer's lost revenue.

The correct result depends on what was agreed with the customer. A higher calculated price is not, by itself, a reason to replace an agreed price.

## What should the office check before sending an invoice?

| Check | Decision it supports |
| --- | --- |
| Work performed and recorded items | Is the bill describing the work that actually happened? |
| Site inputs used by the calculation | Are zone count, pump details, and location accurate? |
| Current rate and calculated rate | Is there a difference to explain? |
| Saved Site terms, customer benefits, and memberships | Is the difference intentional? |
| Notes and job evidence | Does the record explain added work or an exception? |

Use the work-order pricing explanation to investigate a marked service rate. Make an authorized adjustment on a supported editable document when appropriate, then review the final bill. The table is a review process for your team; it does not imply an automatic approval or invoice-blocking workflow.

## Recognize membership pricing

Where a membership benefit explains a below-rule rate, ServeCommand identifies it as a member rate rather than treating the intended discount as a pricing problem.

Owner-tag discounts do not add another discount to covered membership visits. Review the saved membership price before changing that work.

## Resolve missing inputs first

If the Site or office coordinates are unavailable, distance-dependent pricing may not be fully checked. The review can show that distance pricing is unavailable and distinguish the remaining calculation from a complete price.

Resolve missing location information before applying the current calculation. A deliberate fixed Site price remains a separate option where supported.

## Available actions depend on the document

The pricing comparison and the ability to change a price are separate. A pricing explanation can remain visible even when that document cannot be edited. Saving a Site rule is available only on supported surfaces; it is not an action on every document.

Custom lines without a pricing standard cannot be checked in the same way as a service with a resolved rule. The absence of a warning is not a guarantee that every price has been verified.

## Related guides

- [Conditional pricing rules](https://www.servecommand.com/docs/conditional-pricing.md)
- [Owner tags and customer benefits](https://www.servecommand.com/docs/owner-tags.md)
- [Memberships and campaigns](https://www.servecommand.com/docs/memberships-and-campaigns.md)
- [ServeCommand for irrigation businesses](https://www.servecommand.com/irrigation-business-software)

---

> For the complete documentation index, see [llms.txt](https://www.servecommand.com/llms.txt).

# Connect memberships and campaigns

Give customers a clear next step with property-specific membership offers, payment choices, and follow-up informed by existing work.

Source: https://www.servecommand.com/docs/memberships-and-campaigns
Updated: 2026-10-06

Campaign offers and service notices give customers a next step. Memberships record the services and terms they commit to. Connecting the two helps the office distinguish a customer who has received an offer from one whose work is already covered.

## Before you start

Campaigns require access to the Campaigns module and marketing email. Membership offers also require memberships to be enabled for your business, with plans and services configured for the relevant Sites.

## Match the action to the offer

ServeCommand uses different campaign actions for different situations:

| Customer action | What happens next |
| --- | --- |
| See my offer | Opens the plans and prices prepared for the property. |
| Request an estimate | Sends the request to Sales for the team to prepare a quote. |
| Request service | Sends the request to Requests in Command, ready for the office to schedule. |

Requesting service is not the same as confirming an appointment. The office still has a scheduling decision to make.

## Make membership terms clear

A property-specific membership offer presents the included services, term, and available payment choices. Depending on the plan, a customer can pay in advance or pay per visit. Where both choices exist, the offer can show calculated prepay savings.

Acceptance records the services, terms, rates, consent, and signature. Covered visits keep the agreed member pricing. Prepayment covers the included visits for the term; those covered visits are not billed again. Additional work outside the included services remains separate. Per-visit billing uses the agreed member rates as services are delivered.

## Example: an irrigation season offer

An irrigation business prepares a plan covering its chosen seasonal visits for a customer's Site. The customer reviews the included work and available payment choices, then accepts the plan.

Before sending another seasonal offer, the office can review whether that Site already has an active membership, a related offer, or work on the books. This gives the team context for deciding whether further outreach is useful.

Your plans might be named Bronze, Silver, Gold, and Premium, with different included services and rates. These names are examples; ServeCommand does not assume that every tier contains the same visits. Define the service scope and term before presenting the offer.

The services and choices in this example depend on how your business configures its plans. A campaign does not create a customer commitment simply because it was sent.

## How does this help plan seasonal workload?

Separate customers who have committed from those who still need follow-up, then compare that context with work already on the books. An active membership explains which services are covered. A request still needs an office scheduling decision. That distinction helps the team discuss the season using customer commitments rather than treating the entire mailing list as booked work.

Before following up, review Site and service-category coverage. A property may already have a membership, an overlapping offer, or a related job. That context helps avoid asking a customer to buy work they already arranged. It does not automatically balance crew capacity or guarantee an appointment.

## Follow up on the right stage

Campaigns distinguish sent messages and click activity from membership acceptance and booked work. Offer reminders focus on offers still awaiting a customer decision, leaving accepted or booked targets out of that audience.

Coverage information is tied to the Site and service category. It can surface active or renewing memberships, overlapping offers, recent contact, and existing work. A proposed membership is not active coverage, and selecting a customer for a campaign does not mean an email has been sent.

Campaign click activity can include a tracked email link click or a visit to the linked offer or request page. A click does not confirm that a membership was accepted, a visit was booked, or a payment was completed.

Membership acceptance and payment are also separate. A per-visit membership does not require payment for the whole term at acceptance, and a bank prepayment can still be processing after confirmation.

## Is accepted membership value money collected?

No. Keep offer acceptance, service scheduling, and payment status separate when reading the campaign results.

| Signal | What it tells you | What it does not establish |
| --- | --- | --- |
| Sent | The campaign message was sent. | The customer read it. |
| Clicked | A tracked link was clicked or a linked campaign page was visited. | The customer accepted or paid. |
| Accepted | The customer committed to the recorded membership terms. | Every visit is scheduled or the full term has been paid. |
| Payment completed | The relevant payment completed. | All future service work is finished. |

For an illustrative $900 per-visit membership, acceptance records the agreement. The $900 should not be treated as money collected at acceptance. Review payment records separately. ServeCommand campaign follow-up focuses on clicks and customer actions; email opens are not the engagement signal described here.

## Related guides

- [Understand the ServeCommand system](https://www.servecommand.com/docs/overview.md)
- [Owner tags and customer benefits](https://www.servecommand.com/docs/owner-tags.md)
- [Review pricing differences before invoicing](https://www.servecommand.com/docs/invoice-review.md)
- [ServeCommand for irrigation businesses](https://www.servecommand.com/irrigation-business-software)