Maintenance & Hosting Guideline
Department
Summary
Policy and process for hosting, maintenance agreements (MA), and post-delivery warranty. Covers hosting types, MA pricing (25% of project cost/year), 3-month warranty, renewal flow, and activation processes for MA and hosting. Resources tracked in ERPNext for expiry management.
Table of Contents
Purpose
Policy and process for hosting, MA, and post-delivery warranty. Primary readers: AE, PM.
| Outcome |
|---|
| Clear policy for hosting and MA, consistent activation and renewal processes, and resources tracked in ERPNext for expiry management. |
Prerequisites
Before proceeding with this document, please review the following documents:
| # | Document | Purpose |
|---|---|---|
| 1 | Invoicing & Payment Operations Guideline | Understand invoice issuance and payment confirmation |
| 2 | Client Acceptance (UAT) & Go-Live Guideline | Understand go-live preconditions and flow |
| 3 | Project Closure & Handover Guideline | Understand closure and post-closure handoff |
Scope
This guideline covers:
| Included | |
|---|---|
| 1 | Hosting types and costs (WordPress, Static, Custom, Client-owned) |
| 2 | Domain options and costs |
| 3 | MA pricing and scope |
| 4 | 3-month warranty period |
| 5 | MA activation and hosting activation processes |
| 6 | Renewal flow for hosting, domains, and MA |
| 7 | Resource tracking in ERPNext |
This guideline does not define detailed deployment tooling or incident response. Those live in Technology-owned documents when needed.
Operating Model
| # | Operating Model |
|---|---|
| 1 | Asana is the system of record for work tracking, approvals, and handoffs. |
| 2 | Use checkpoints and decision points: don’t move forward until the previous step is “done”, and branches are explicit. |
| 3 | Handoff order: upstream defines handoff artifacts/exit criteria; downstream defines execution after handoff. |
Definitions
| Term | Definition |
|---|---|
| Hosting | Infrastructure (servers, domains, environments). Has a creation date and an expiration date. |
| MA (Maintenance Agreement) | Maintenance support (unlimited bug fixes) for a defined period. Separate from hosting. |
| Project cost | Total project cost at final acceptance (includes change orders signed before delivery). Locked at delivery for MA calculation. |
| Warranty | 3-month period after project closure with unlimited bug fixes included. |
| Resource | A trackable item in ERPNext: Server, Domain name, or MA. |
Hosting Types
Hosting type is determined by project architecture (requirements, SOWs), not by client choice.
| Type | Domain | Hosting | Notes |
|---|---|---|---|
| WordPress | Free 1st year; then ~800–1000 THB/year or free Kiluth subdomain | Free 1st year; then 1500 THB/month | Provider tier for year 1 |
| Static (Vercel) | ~800–1000 THB/year or free Kiluth subdomain | Free (Vercel free tier) | Provider tier |
| Custom (DigitalOcean) | ~800–1000 THB/year or free Kiluth subdomain | ~800–1000 THB per environment | PM decides which environments |
| Client-owned | Client provides | Client provides | MA only if Kiluth manages |
Custom Environments
| Environment | Billing | Notes |
|---|---|---|
| DEV, UAT | Complimentary during 3-month warranty; ~800–1000 THB each after | Taken down after warranty if client does not purchase |
| Staging, Production | Billed from spin-up | ~800–1000 THB per environment |
Domain
- Paid domain: ~800–1000 THB/year. Tracked as a Resource in ERPNext.
- Free Kiluth subdomain: Track as a Resource in ERPNext (type: Domain name) with the same Expiry date as the associated server. Kiluth is migrating to project-ID-based subdomain format (e.g.
PROJ-0025.demo.kiluth.com). - Domain purchase follows Third-Party Purchases (Phase 3); domain renewal follows Phase 1 (Invoice Issuance).
Hosting vs MA
| Concept | Meaning |
|---|---|
| Hosting | Infrastructure. Has creation date and expiration. |
| MA | Maintenance support (bug fixes). Requires an active MA plan. |
Hosting and MA are separate. Hosting can exist without MA; MA can exist without Kiluth hosting (e.g. client-owned when Kiluth manages).
Client-owned: MA required only when Kiluth manages the client’s hosting. If the client manages it themselves, MA is not required.
MA Pricing
- Annual rate: 25% of total project cost per year
- Shorter periods: Prorated by month
Formula: ((25% of project cost) / 12) × number of months
Example: 3 months MA = ((25% of project cost) / 12) × 3
MA without Kiluth hosting: Yes. Client can purchase MA only for client-owned hosting when Kiluth manages.
3-Month Warranty
After project closure and all deliverables are delivered:
- 3 months warranty for every system
- Unlimited bug fixes during this period
- Scope: Bug fixes only (no change requests)
Custom projects: DEV and UAT environments are included during the 3-month warranty.
After Warranty
| Scenario | Outcome |
|---|---|
| No MA purchased | No further work for the client |
| MA purchased | Unlimited bug fixes within the MA period |
| Custom, no DEV/UAT purchased | DEV and UAT environments are taken down |
Change Requests
Change requests are never part of warranty or MA.
Process: Scope → Quote → Change order → Work. See Contracting & Change Order Workflow Guideline.
Renewal Flow
Use the same flow for hosting, domain, and MA renewals. ERPNext sends expiry reminders (30, 15, 5, 3, 1 days before, and on expiry). When AE receives these notifications, AE derives and sets Notice, Decision, and Renewal notice dates (e.g. in Asana) so that client decision, payment, and Delivery/Technology execution fit before expiry. AE should also track resources proactively in case notifications are missed.
Timeline
| Step | When | Owner | Action |
|---|---|---|---|
| 1. Notice | Expiration − 1 month | AE | Notify client |
| 2. Decision | Notice + 2 weeks | Client | Decide and pay |
| 3. Renewal notice | ≤ Expiration − 1 week | AE | Notify PM |
| 4. Renewal | Before expiration | PM | Execute renewal |
Process flow: Notice client → 2 weeks for client to decide and pay → 1 week for PM to receive renewal notice → 1 week to renew before expiration.
Step 1: Notice (Expiration − 1 month)
AE notifies the client that the resource (hosting, domain, MA) is about to expire.
Process:
| Action | |
|---|---|
| 1 | AE identifies resources expiring (via ERPNext notifications or manual tracking) |
| 2 | AE sends written notice to client: resource name, expiration date, renewal cost, payment deadline |
| 3 | AE documents notice in Asana (link to resource, notice date, client response if any) |
Checkpoint: Client has received notice. Client has ~2 weeks to decide and pay.
Step 2: Decision (Notice + 2 weeks)
Client decides to renew or not. If renewing, client pays by this date.
Process:
| Action | |
|---|---|
| 1 | Client decides: renew or let expire |
| 2 | If renewing: AE requests Finance to issue renewal invoice (per Invoicing & Payment Operations Guideline) |
| 3 | Client pays. Finance confirms. AE records in Asana |
| 4 | If not renewing: AE documents decision. No further action |
Checkpoint: By Decision date, client has decided and paid (if renewing).
Step 3: Renewal Notice (≤ Expiration − 1 week)
AE notifies PM to execute the renewal.
Process:
| Action | |
|---|---|
| 1 | AE creates Asana task for PM: “Renew resource – [Client Name] – [Resource] – Expires [Date]“ |
| 2 | AE attaches: resource details, payment confirmation (if applicable), renewal scope |
| 3 | PM has up to 1 week to execute renewal before expiration |
Checkpoint: PM has received renewal notice. Renewal can proceed.
Step 4: Renewal (Before expiration)
PM executes the renewal (extend hosting, renew domain, extend MA). Update resource record in ERPNext with new expiry date.
Process:
| Action | |
|---|---|
| 1 | PM executes renewal (provision extension, domain renewal, MA extension) |
| 2 | PM updates Resource record in ERPNext: new Expiry date, Cost (if changed), Charge (if changed) |
| 3 | PM confirms renewal complete in Asana task |
| 4 | AE verifies resource is renewed before expiration |
Checkpoint: Renewal completed before expiration. Resource record updated in ERPNext.
Renewal Rules
| Rule | Description |
|---|---|
| Expiration | Per resource. Each resource has its own duration. |
| Align dates | Align MA and hosting renewal dates per project where possible to simplify tracking. |
| Grace period | None. Strict cut-off at expiration. |
MA Purchase Window & Reminder
- Client can purchase MA: From project start until end of 3-month warranty
- Written reminder: At day 0 of warranty (delivery/go-live). AE sends: “You have 3 months warranty. MA is available for purchase until warranty ends.”
- Client decides: Client has the right to purchase or not purchase MA
MA Activation Process
When the client decides to purchase MA, follow these steps. Use Asana for task assignment and requests (same as other flows). See Invoicing & Payment Operations Guideline for invoice and payment flow.
Process flow: Request MA invoice → Request MA contract → Confirm payment & brief PM → PM kick-off & execute MA plan → Register MA resource in ERPNext.
Step 1: Request MA Invoice
AE requests Finance to issue an MA invoice. AE provides details (project cost, MA period, amount). Finance creates the invoice via the Kiluth portal, returns it to AE, and keys in ERPNext.
Prerequisites: Client has decided to purchase MA. AE has calculated MA amount (25% of project cost / 12 × months).
Process:
| Action | |
|---|---|
| 1 | AE creates Asana task using the template below |
| 2 | Finance creates invoice via New Sales Invoice |
| 3 | Finance attaches invoice in task, replies with invoice number + issued date |
| 4 | AE sends invoice to client and tracks payment |
| Asana Card Template | |
|---|---|
| Title | Issue MA invoice – [Client Name] – [Project Title] |
| Assignee | Finance |
| Description | Please issue an MA invoice for this project. References • Project card: [Link] • Project cost (at final acceptance): [Amount] MA details • MA period: [X months] • Amount: [((25% of project cost) / 12) × months] • Due date: [Date] Output • Invoice link/file: [Link] • Invoice number: [Number] • Issued date: [YYYY-MM-DD] |
Checkpoint: Proceed only when invoice is issued, linked in Asana, and sent to client.
Step 2: Request MA Contract
AE requests Legal for MA contract template. AE tailors it to the client and obtains signed contract.
Prerequisites: MA invoice has been issued (Step 1).
Process:
| Action | |
|---|---|
| 1 | AE creates Asana task for Legal (request MA contract template) |
| 2 | Legal provides MA contract template |
| 3 | AE tailors contract to client (project, period, amount) |
| 4 | AE obtains signed contract from client |
| 5 | AE links signed contract in Asana |
Checkpoint: Proceed only when signed MA contract is linked in Asana.
Step 3: Confirm Payment & Brief PM
After signed contract and Finance confirms payment received, AE briefs and assigns PM the MA plan.
Prerequisites: Signed MA contract exists. Client has paid. Finance has confirmed payment (record in Asana per Invoicing guideline).
Process:
| Action | |
|---|---|
| 1 | Finance confirms payment receipt |
| 2 | AE records confirmation in Asana (comment with date, @mention Finance) |
| 3 | AE briefs PM on MA plan (period, scope, client contact) |
| 4 | AE assigns PM to execute MA plan via Asana |
Checkpoint: Proceed only when payment is confirmed and PM is briefed and assigned.
Step 4: PM Kick-off & Execute MA Plan
PM kick-offs and executes the MA plan (bug fix support within MA period).
Prerequisites: PM is briefed and assigned.
Process:
| Action | |
|---|---|
| 1 | PM kick-offs MA plan with client (if needed) |
| 2 | PM executes MA plan: receives and triages bug fix requests |
| 3 | PM coordinates with Technology for fixes |
| 4 | PM tracks work in Asana |
Checkpoint: MA plan is active. Bug fix requests are handled per MA scope.
Step 5: Register MA Resource in ERPNext
PM creates MA resource record in ERPNext. Assigns Created by (PM), Issued by (PM), Tracked by (AE). ERPNext notifications are pre-configured at DocType level; AE derives Notice, Decision, and Renewal notice dates when they receive expiry reminders.
Prerequisites: MA activation is complete (Steps 1–4).
Process:
| Action | |
|---|---|
| 1 | PM creates Resource record via New Resource (stored in ERPNext) |
| 2 | Resource type: MA |
| 3 | Fill: Customer, Project, Description, Identifier (Project ID), Created date, Issue date (optional), Expiry date, Cost (Kiluth’s internal MA cost = 25% of project cost ÷ 12 × months), Charge (0 during warranty; MA amount when client pays), Provider (Kiluth), Environment (Production), Created by (PM), Issued by (PM), Tracked by (AE) |
Checkpoint: MA resource exists in ERPNext. Expiry reminders are sent automatically to Tracked by.
Hosting Decision & Hosting Activation Process
Hosting Decision
Before go-live, the client must decide: host with Kiluth or host themselves.
Timing:
| Rule | |
|---|---|
| 1 | Hosting decision must be made before go-live execution. |
| 2 | PM sets the deadline for the decision (e.g. during UAT preparation or early in UAT, allowing time for hosting activation before go-live). |
| 3 | PM communicates the deadline to AE and client. Document the deadline in Asana. |
| 4 | If the client has not decided by the deadline, timeline is adjusted (go-live date shifts). |
Outcomes:
| Client decision | Action |
|---|---|
| Host with Kiluth | Proceed to Hosting Activation Process. |
| Host themselves | No further action. Deliver deliverables normally. |
| Host on their machine + Kiluth manages | PM estimates scoping fee; AE presents to client. If agreed, proceed to Hosting Activation with client-owned hosting terms. |
Hosting Activation Process
When the client hosts with Kiluth, follow these steps. See Client Acceptance (UAT) & Go-Live Guideline for go-live flow.
Process flow: Gather hosting details → Request hosting invoice (if not paid) → Confirm preconditions & request go-live kick-off → Register resources in ERPNext.
Step 1: Gather Hosting Details
PM gathers hosting details with Technology support (Dev, DevOps, Infra Eng.). Decide on hosting type, environments, domain. Technology provides technical information (specs, provider, costs).
Prerequisites: Client has decided to host with Kiluth. Hosting type is determined by project architecture (WordPress, Static, Custom).
Process:
| Action | |
|---|---|
| 1 | PM coordinates with Technology to determine hosting requirements |
| 2 | PM documents: hosting type, environments (DEV, UAT, Staging, Production), domain (paid or free Kiluth subdomain) |
| 3 | PM documents costs per Hosting Types (e.g. ~800–1000 THB per environment for Custom) |
| 4 | PM aligns with AE on commercial terms and presents to client |
| 5 | Client agrees and signs off (or documented in meeting minutes) |
Checkpoint: Proceed only when hosting details are agreed and documented. Client has agreed to host with Kiluth.
Step 2: Request Hosting Invoice (If Not Paid)
AE requests invoice from Finance if hosting has not been paid. Hosting can be paid at project start or before go-live.
Prerequisites: Hosting details agreed (Step 1).
Process:
| Action | |
|---|---|
| 1 | AE checks if hosting was paid (e.g. in initial contract) |
| 2 | If not paid: AE creates Asana task for Finance using the template below |
| 3 | Finance creates invoice via New Sales Invoice |
| 4 | Finance attaches invoice in task, replies with invoice number + issued date |
| 5 | AE sends invoice to client and tracks payment |
| Asana Card Template | |
|---|---|
| Title | Issue hosting invoice – [Client Name] – [Project Title] |
| Assignee | Finance |
| Description | Please issue a hosting invoice for this project. References • Project card: [Link] • Hosting details: [Link to Step 1 output] Invoice details • Hosting type: [WordPress / Static / Custom] • Items: [e.g. Domain, Hosting DEV, Hosting UAT, Hosting Production] • Amount: [Amount] • Due date: [Date] Output • Invoice link/file: [Link] • Invoice number: [Number] • Issued date: [YYYY-MM-DD] |
Checkpoint: Proceed only when hosting is paid (or was already paid at project start). Finance confirms payment; AE records in Asana.
Step 3: Confirm Preconditions & Request Go-Live Kick-off
After Finance confirms payment, go-live planning and UAT test cases approved/signed by client, and all signed documents obtained: AE requests PM to kick-off go-live.
Prerequisites: Hosting paid. Go-live plan exists. UAT test cases approved/signed by client. All signed documents obtained by AE.
Process:
| Action | |
|---|---|
| 1 | AE verifies: Finance confirms payment |
| 2 | AE verifies: Go-live planning and UAT test cases approved/signed by client |
| 3 | AE verifies: All signed documents obtained |
| 4 | AE creates Asana task to request PM to kick-off go-live |
| 5 | PM proceeds with go-live execution per Client Acceptance (UAT) & Go-Live Guideline |
Checkpoint: Go-live preconditions met. PM is authorized to execute go-live.
Go-live precondition: Hosting must be paid and UAT test cases signed before go-live execution.
Step 4: Register Resources in ERPNext
PM registers all resources (servers, hosting, domains) in ERPNext. Technology reports resources to PM. AE is assigned Tracked by.
Prerequisites: Go-live is executed. Resources (servers, hosting, domains) are provisioned.
Process:
| Action | |
|---|---|
| 1 | Technology reports all resources to PM (name, IP, URL, environment, cost, expiry) |
| 2 | PM creates Resource records via New Resource for each resource (stored in ERPNext) |
| 3 | Resource types: Server, Domain name (as applicable) |
| 4 | Fill: Customer, Project, Description, Identifier (IP for Server, domain name for Domain name), Created date, Issue date (optional), Expiry date, Cost (Kiluth’s actual expense in THB — record once confirmed from bank statement), Charge (0 during warranty; client billing amount after warranty), Provider, Environment, Created by (Technology), Issued by (PM), Tracked by (AE) |
Checkpoint: All resources are registered in ERPNext. Expiry reminders are sent automatically to Tracked by (AE).
Roles & Responsibilities
| Role | Responsibility |
|---|---|
| Account Executive (AE) | MA reminder at day 0; renewal notices; resource tracking; MA activation coordination; hosting invoice coordination |
| Project Manager (PM) | Hosting details; hosting activation; resource registration (all resource types); go-live coordination |
| Technology | Technical hosting details; resource creation; reporting resources to PM |
| Finance | Invoicing; payment confirmation; income/expense recording in ERPNext |
| Legal | MA contract template and tailoring |
ERPNext Resources
Resources are tracked in ERPNext. Create new resources via New Resource.
Architecture
| Layer | System | Role |
|---|---|---|
| Source of truth | ERPNext | Resource records (Server, Domain name, MA). |
| Entry point | Kiluth Portal | New Resource (creates Resource in ERPNext). |
| Display / management | ERPNext + Portal | Browse, filter, and manage resources in ERPNext. |
Flow: Manual entry via Portal → ERPNext (storage) → ERPNext notifications for renewal tracking.
DocType: Resource Types
| Field | Description |
|---|---|
| Name | Resource type name (e.g. Server, Domain name, MA) |
Default types: Server, Domain name, MA
DocType: Resources
| Field | Type | Description |
|---|---|---|
| Resource type | Link | Link to Resource Type (Server, Domain name, MA) |
| Customer | Link | Link to Customer |
| Project | Link | Link to Project |
| Description | Text | Short description; name, IP, URL, or other type-specific details |
| Identifier | Data | IP (Server), domain name (Domain name), Project ID (MA) |
| Created date | Date | Anchor date for the resource. Use the last invoice payment date for completed/delivered projects. For in-flight projects (no go-live yet), use the planned delivery date from the SOW. Server spin-up dates are not used — they are unreliable because servers may be migrated or rebuilt. |
| Issue date | Date | When the resource was issued (e.g. MA activation date, hosting delivery date). |
| Expiry date | Date | When the resource or contract ends (for renewal). See Expiry Date Rules below. |
| Cost | Data | Kiluth’s actual expense (THB, from bank statement). Record the actual amount once confirmed from the provider. |
| Charge | Data | Amount billed to the client. Set to 0 during warranty period; set to the client billing amount after warranty. |
| Provider | Text | Hosting provider (e.g. DigitalOcean, Vercel, Registrar, Kiluth) |
| Environment | Text | Use “Production” when applicable; blank otherwise |
| Created by | Link | Link to Employee. Typically: Technology (Server, Domain); PM (MA). |
| Issued by | Link | Link to Employee. Typically: PM (Server, Domain, MA). |
| Tracked by | Link | Link to Employee. Typically: AE (all resource types). |
Who fills what (by resource type)
| Resource type | Created by | Issued by | Tracked by |
|---|---|---|---|
| Server, Domain name | Technology (Dev, DevOps, Infra, IT) | Delivery (PM) | Account Management (AE) |
| MA | Delivery (PM) | Delivery (PM) | Account Management (AE) |
Who enters: PM enters all resource records in ERPNext.
Expiry Date Rules
Every resource must have an expiry date. Resources without an expiry date do not trigger renewal notifications, which allows stalled projects to accumulate unchecked costs indefinitely.
| Scenario | Expiry Date |
|---|---|
| MA (warranty) | Created date + 3 months |
| DEV / UAT (warranty) | Go-live date + 3 months (taken down after warranty if client does not purchase) |
| Staging / Production (paid, time-limited) | Last payment date + billing period (per invoice) |
| Domain — Kiluth subdomain | Same expiry date as the associated server |
| Domain — paid (Namecheap or similar) | Registration date + 1 year (or per invoice) |
| In-flight project (no go-live yet) | Planned delivery date + 3 months (applies to all resource types: DEV/UAT servers, staging, MA) |
Rule for in-flight projects: When a resource is provisioned for a project that has not gone live yet (e.g. server created during active development), use the planned delivery date as the Created Date anchor for all resources, and set Expiry to planned delivery date + 3 months. This applies to all resource types (DEV server, UAT server, MA). The +3 months buffer accounts for the post-delivery warranty window and creates a renewal trigger after the planned delivery passes — forcing a reassessment of whether the resource should continue. If the project is running late, AE extends the expiry date with a new agreed date. If the project is stalled with no clear timeline, the resource can be taken down to avoid ongoing cost.
Why not server spin-up date: Server creation dates are not reliable as an anchor because servers can be migrated, rebuilt, or replaced without changing the project timeline. The last invoice payment date is preferred as it is tied to a verifiable event in ERPNext.
Notifications
ERPNext sends notifications to Tracked by (AE) automatically:
| When | Notification |
|---|---|
| Resource created | Assigned to you |
| 30, 15, 5, 3, 1 days before expiry | Expiry reminder |
| On expiry date | Resource expired |
| Expiry date updated | Renewal confirmed |
Internal planning dates (AE)
When AE receives notifications, AE derives internal planning dates and sets them (e.g. in Asana or a tracker). These dates must allow time for Delivery and Technology to execute renewal or take down the resource.
| Date | Purpose |
|---|---|
| Notice date | When to first reach out to client (e.g. expiry − 1 month) |
| Decision date | When client must decide renew or not (e.g. notice + 2 weeks) |
| Renewal notice date | When to send final reminder before execution (e.g. expiry − 1 week) |
AE works backwards from expiry date so that client decision, payment, and Delivery/Technology execution fit before expiry.
Data Entry
| Rule | Description |
|---|---|
| Manual entry | All resources are entered manually. No sync from provider APIs for now. |
| Who enters | PM enters all resource records (hosting at go-live, MA at MA activation). Technology reports resource details to PM. |
Related Documents
| Document | Purpose |
|---|---|
| Invoicing & Payment Operations Guideline | Invoice issuance and payment confirmation |
| Client Acceptance (UAT) & Go-Live Guideline | Go-live preconditions and flow |
| Project Closure & Handover Guideline | Closure and post-closure handoff |
| Contracting & Change Order Workflow Guideline | Change orders and contracting |