Rollout projects set the dates
A rollout has a date. Sign-off, adaptations and layout have to be ready by then, even if development happens to be full.
ERP for software vendors: customer requests, releases and maintenance in one system.
You sell licences, and with them the promise that the software will not stand still. At the same time, rollout projects, customer requests, your own roadmap and support are all waiting for the same developers. In teamspace, every order and every plan sits in one system. You see up front what a shift or a new order sets off, so you can act instead of only reacting.
In short
What is an ERP for software vendors?
An ERP for software vendors is business software that brings every commercial and planning process around your own software product together in one system. That covers quoting and sales, product development, customer projects, releases, licence and maintenance contracts, support and billing. A good ERP makes these areas work together seamlessly, so that a software company keeps sight of dates, resources and running contracts despite finite development capacity.
Three strands belong in the same system:
- Development on your own product, it hangs off the delivery date
- The rollout at the individual customer, it hangs off the customer's date
- The running contracts for licences, maintenance and support, they run on independently of both
Your day to day
Several things run in parallel, and none of them waits for the others.
Anyone who develops and sells their own software product knows these pressures. So do we, and we offer a solution for them.
The day to day has to keep running
Support requests, licences, invoices. Yesterday's customer will not wait for the next release to be finished.
Adaptations belong in the release
What one customer paid for ends up with everyone. So it is tested and shipped as a batch, not slipped in one by one.
Your own roadmap must not drop off
Whatever no customer ordered loses every argument about priority. Until it gets fixed hours in the release, like a paid order.
Not every ERP is the same
The small difference that changes everything.
Every development project has to be coordinated, tested and free of defects by the release date. That is something other than a software project for a single customer, and it calls for different tools.
One project for one customer
- Each customer gets their own project with their own date.
- What is sold gets built. The order of work follows the contract.
- Testing and sign-off happen with that one customer.
- Revenue arises in the project and ends with sign-off.
One product for all customers
- Everything built on the product goes into the same release, whoever ordered it.
- Paid customer requests and your own roadmap fight over the same hours.
- Testing happens as a batch, because every change reaches every customer.
- Licences, maintenance and support run on regardless. That is what you live on.
From our own house
“Without teamspace we could not run our business. We build software ourselves, and we use teamspace for every one of our administrative processes, no other system.”
Thorsten Lenk Founder and CEO of 5 POINT AG
Invoices, release planning, support tickets: it all sits in the same system here. The video further down shows what that looks like day to day.
From the sale to the shipped release
Modules that work together and processes mapped the way you run them make your day easier.
Quote, release and running contract interlock because they use the same data. Nobody types anything a second time.
The order becomes the work package
Once the adaptation is sold, the quote becomes the order in one click, and the order becomes the project. What the customer paid for stays attached to the package until it reaches them.
The release date is a milestone
Work packages and the people building them hang off that milestone. Whether you ship monthly, every six weeks or twice a year is your call.
The recurring base bills itself
Licences and maintenance run on as a recurring contract in the rhythm you set. Support beyond the included hours is added on a time and material basis.
The release cadence
Customer adaptations and your own roadmap compete for the same resources.
Both end up in the same release, because every change to the product has to be tested before it goes out to all customers. Without fixed windows, testing runs away with you. And you can only decide between things that sit side by side.
Bezahlter Anpassungswunsch Ein Kunde zahlt für eine Erweiterung und erwartet sie zu einem Termin
Eigene Roadmap Was die Software für alle Kunden aktuell hält, auf eigene Kosten
Q1 v9.2
ausgeliefert Kapazität 700 h
Schnittstelle Kunde Nord 160 h
E-Rechnung Empfang 120 h
Q2 v9.3
ausgeliefert Kapazität 680 h
Rechte-Modell 210 h
Import Altdaten 90 h
Q3 v9.4
in Arbeit Kapazität 720 h
Freeze 24.07., danach nur noch Test
Auswertung Kunde Süd 120 h
Suche im Standard 80 h
Pflichtfeld Steuer 64 h
Q4 v9.5
geplant Kapazität 640 h
Mobiler Zugriff 180 h
Zweite Auswertung Süd 40 h
aus Q3 verschoben
Der Vertrieb sagt keinen Termin zu, den die Entwicklung nicht halten kann: was nicht mehr hineinpasst, steht sichtbar im nächsten Fenster.
The example shows our own cadence with four deliveries a year. Yours might be monthly, every six weeks or twice a year. A milestone in teamspace is a date you set, not a prescribed quarter. Up to the freeze you can still rearrange the plan.
Before you promise
With teamspace you plan in concrete terms, and surprises become visible too.
The expensive promise is the one someone makes without knowing the free hours. So the backlog holds everything side by side. Whatever has a promised date carries a date, everything else carries a priority. Some of it belongs to a larger project, some stands on its own as a single work package.
- The next release draws from the backlog, taking what sits at the top, until the hours are used up.
- The free hours come from your people's capacity. Leave and absence are already deducted.
- The difference is the answer. Whatever does not fit moves visibly to the next window, instead of quietly slipping.
If someone calls in sick or an order falls away, you see it in the plan straight away, not in the next status report. Up to the freeze you can rearrange. After that the window is closed, because testing begins.
“Time tracking is far simpler and more convenient than in Excel.”
What vendors gain
Three things nobody has to keep in their head any more.
The resource plan shows the free hours, licences and maintenance bill themselves, and on the ticket you can set in advance which support time is automatically billable against a time record.
Cadence
The date holds because the hours are reserved.
Work packages hang off the milestone, and so do the people who build them. Both sit side by side before anyone promises anything.
- Every delivery date is a milestone of its own
- Free hours next to the hours required
- Leave and absence are already deducted
Recurring base
Licences and maintenance bill without a reminder.
The contract renews in the rhythm you set and issues its own invoice.
- Recurring contract on a monthly, quarterly or annual cycle
- Flat fee with included hours, the overflow on time and material
- Incoming payments are reconciled daily
Support
Every support hour knows its contract.
Email and phone requests become tickets that carry the promised response time as remaining time. Paid hours are booked straight onto the ticket.
- Service level per customer, remaining time as a traffic light
- Time booked on the ticket and billed through the contract
- Open tickets, projects and quotes on the same customer
Between the request and the version
Where money is left lying when sales and development keep separate lists.
- A date is promised before anyone knows how many hours are free until then.
- A small adaptation gets built with no order behind it. It never appears on an invoice.
- Support works off hours that went past the included allowance long ago.
- The work is handed over, the invoice waits, because nobody triggered it.
In teamspace, order, release, ticket and invoice hang together. What has been delivered does not get stuck between two lists.
The path of an adaptation
From the customer request to the shipped version.
Seven steps, with nobody copying data from a quote template into a ticket tool and on into the development plan.
- 1
Cost the quote
This is where the real work sits: scope, effort, price. Everything else grows out of it.
- 2
Order and project follow from it
The accepted quote becomes the order, the order becomes the project with its work packages. No project without an order.
- 3
Queued in the backlog
With a date if one has been promised, otherwise with a priority. The next release pulls the most important items until the hours are used up.
- 4
Worked off in the sprint
The sprint takes on as many packages as the team's time allows. How long it runs is your decision. Ours is two weeks.
- 5
Freeze, then the test phase
Nothing joins after the freeze. Whatever is not finished goes into the next window. Then what goes out to all customers gets tested.
- 6
Reported done, invoice triggered
The person handling it reports the handover, and the invoice comes out of the project. Nobody hunts down the line items again.
- 7
Taken into the maintenance contract
The shipped extension runs on in the customer's existing order, with service and licence data on the same contact.
How we run our own house on it
We are a software vendor ourselves, and we run our administration, our planning and our billing in teamspace. In this walkthrough our CEO goes through what that looks like: the running order per customer, our four deliveries a year, the ticket with a promised response time. The cadence is ours, teamspace does not prescribe one.
How do we use teamspace? A walkthrough
Invoices, order processing, release and sprint planning, support with service levels, HR and sales: a tour through the working processes of 5 POINT AG.
Sprint
Only what there is free capacity for goes into the sprint log.
The team then works off every task planned in the sprint log, so that a running version exists again once the sprint ends.
- The team distributes the packages before the sprint, as far as each person's time goes.
- Classic and agile side by side: the same work package moves onto a board and is worked on there. Two views, one item.
- Booked hours flow back into the planned versus actual figures of the project and into the team's utilisation.
By the end of the planning everyone knows what they are doing. And nobody has to work out whether the week even holds that many hours.
Introductory call
Tell us about your next release.
One sentence about your cadence and about whatever is jammed right now is enough to start. There is nothing to prepare.
Practical tip
One support contract per customer
If you sell your own product, each customer usually brings recurring fees plus charges that arise as needed. The sensible setup is exactly one support contract per customer, holding the licences, the included hours and the rates for additional support, and billing itself in full. Real projects get a separate order and are billed separately.
- The order runs on instead of being closed: as a line item over a duration, in the rhythm you set, renewing automatically until someone cancels or pauses it.
- Support is covered up to the included hours. Only what goes beyond is added on time and material, on the same document.
Licence count
Seven added, five gone, and the invoice is still right.
If you bill by duration and by the number of licences, keeping track of the changes customers ask for during the year is often laborious. teamspace works it out automatically and, if you want, adjusts the contract terms to your rules as well.
- The count comes from the documents. teamspace adds up the line items from all of a customer's orders into one figure with a cut-off date.
- The movement stays visible. The history shows when licences were added and when they were reduced.
When the next recurring invoice is due, the count is already there.
Comparison
Four tools or one set of data.
Board, Excel, ticketing, SharePoint: each of them is good in its own field. It is just that the development board does not know the order and the filing system does not know the work package. Everything in between is done by hand.
Feature
Various separate tools
teamspace
Recommended Free development hours visible before you promise
Order and work package hang together
manual
Invoice triggered from the project
Licences and maintenance bill themselves
manual
Ticket knows the maintenance contract and its allowance
Paid support billed through the contract
E-invoice where the hours were booked
Hosting in an ISO 27001 certified data centre in Frankfurt
varies
After the invoice
Unpaid invoices surface before anyone goes looking for them.
Anyone issuing many small invoices a month cannot follow each one individually. The system takes that part over.
- The banking interface reconciles incoming payments daily. It only checks, it never triggers a payment itself.
- Reminders come in stages: a payment reminder after a grace period, then the further stages with their own templates.
- Unbilled time and costs can be reported on deliberately, so nothing sits around for months.
The banking interface belongs to the enterprise edition, the dunning run to the billing module.
Who it is for
Which software vendors get the most out of this.
teamspace suits vendors who build their own product, keep developing it and support their customers' day to day operation. These three shapes show it most clearly.
Vendors of their own standard software
- Customer adaptations and your own standard in one plan
- Delivery dates as milestones, in your own cadence
- Licences and maintenance as a running contract per customer
Providers of software by subscription
- Recurring billing in a fixed rhythm
- Incoming payments and reminders run automatically
- Support with included hours, overflow on time and material
Development houses with customer projects
- No project without an order, almost no order without a quote
- Planned versus actual and contribution margin per project, up to date daily
- Contractors in the same resource pool as the permanent team
Fit
Which software vendors teamspace suits, and which it does not.
Less of a fit
- Pure development teams with no commercial business of their own, looking only for a board for tasks.
- Vendors with no maintenance, licence or support business, where nothing runs on after delivery.
- Self-service products sold entirely by card on the web, with no order behind them.
- Stock and trade with inventory. What is managed here is the release, not a warehouse.
A good fit
- Vendors of their own product who bring paid customer adaptations and their own roadmap into the same release.
- Houses whose revenue comes in good part from licences, maintenance and support contracts.
- Teams where several developers compete for the same weeks and dates still get promised.
- Software houses from a dozen staff up to several hundred.
Sales
An enquiry from the website becomes a sales opportunity.
Anyone selling a product usually sells it to many similar customers. What counts then is less the single conversation than the view across all the live ones.
- The enquiry becomes a sales opportunity, together with the contact, if it was not on file yet.
- Two enquiries from the same company show up straight away, instead of reaching two people in parallel.
- The funnel shows at which stage conversations break off most often, and how many quotes lead to a deal.
Quote, order, project and the later tickets then hang off the same customer. Sales opportunities and the funnel belong to the enterprise edition, customer management itself is included from office upwards.
What is included
Features for software vendors at a glance.
Included in the plan, with no per-module surcharge. A few items belong to the enterprise edition: capacity planning, the sales forecast, the banking interface and the handover to DATEV.
Product and release
- Milestones for delivery dates, with an early warning date
- Global milestones spanning several projects
- Work packages with planned versus actual and assigned staff
- Classic and agile in the same project, with backlog and sprint
- Milestone trend analysis from the project reports
Order and billing
- Order and project from the quote in one click
- Paid adaptation at a fixed price or on time and material
- Recurring contracts for licence and maintenance fees
- Support contract with included hours, overflow on time and material
- E-invoicing as ZUGFeRD or XRechnung, with no second tool
Operations and steering
- Tickets from email, phone and web form
- Service level per customer, remaining time as a traffic light, escalation before the deadline
- Capacity planning across teams, with absence already deducted
- Time booked onto a project, a ticket or a contract
- Post-costing: what was sold against what was actually built
Next step
We speak as one vendor to another.
Show us a customer order that is meant to go into your next release. We will show you how it runs here, through quote, order, milestone and invoice.
Modules
What borders on planning, recurring revenue and support.
Six areas where the work of a software vendor comes together, from release planning to the recurring invoice.
Project management
Work packages on the milestone, classic and agile in the same project, with backlog and sprint.
Learn moreCapacity planning
How many development hours are actually free before the next delivery date.
Learn moreTime tracking
The hour booked lands on the work package and counts in the planned versus actual for the release.
Learn moreCRM software
The customer with their contract, their service level and every licence they hold.
Learn moreService desk software
Enquiries about the shipped product, with remaining time and booking onto the contract.
Learn moreInvoicing software
Licences and maintenance in a fixed cycle, receivables in view, e-invoicing with no extra tool.
Learn moreWhere the line runs
What separates a software house from a systems house and an IT service provider.
All three sell work to business customers, but the commercial centre of gravity sits elsewhere in each case. A systems house also trades third-party hardware and licences, which appear as separate items alongside its own work on the invoice. An IT service provider delivers and operates projects for individual customers. A software house builds a product that is the same for every customer and ships it in its own cadence. Software for software vendors therefore has to carry that cadence, not just the single project.
The second difference lies in the revenue. A house with its own product lives off its recurring base. Licences, maintenance and support contracts run on even when no project is under way. Software that fits carries these as recurring contracts, reconciles incoming payments and bills support beyond the included hours on a time and material basis.
From that follows the third difference, the order in which decisions get made. Anyone planning customer projects decides per project. A vendor decides once for everyone before each delivery date: which paid customer request and which point on the roadmap get the scarce hours? That decision needs order, work package, date and free hours in one picture. It decides whether a promise holds.
Why teamspace
What stands behind the software.
A vendor ourselves, since 1999
We have been building this product for more than 25 years in Darmstadt, self-funded and without an investor. Whoever decides on the roadmap here knows your question from their own Monday morning.
Operated from Frankfurt
Your data sits in an ISO 27001 certified data centre in Frankfurt am Main and is processed exclusively within the EU. The certification is held by the data centre, not by teamspace itself. We keep that line clean, tenders included.
One system instead of four tools
The request that was sold, the work package in the release, the hour booked and the invoice are the same matter from four angles. None of it gets exported.
Terms
Six terms from a software vendor's working week.
Words that keep coming up between sales, development and support.
- ERP for software vendors
- An application that carries a software vendor's product and commercial business on one set of data: quote, order, work package, delivery date, support ticket and recurring invoice.
- Release window
- The time until the next delivery date, bounded by the hours that are free before then. In teamspace it is a milestone with assigned staff and work packages. How long the window runs is up to you: monthly, six-weekly, quarterly or twice a year.
- Work package
- The smallest unit you can plan in a project. It carries planned and booked time, hangs off a milestone and moves onto a board for agile work.
- Recurring contract
- The order that is never closed. It renews by itself and issues its invoice in the cycle you set. For a house with its own product, it is the form in which licences and maintenance turn into revenue.
- Included hours
- The time covered by the flat fee in a maintenance or support contract. As long as it lasts, the work is covered. Only the overflow is billed on time and material.
- Service level
- The response time you have promised a customer in their support contract. It runs on the ticket as remaining time, so support can see what comes first.
Other industries
Solutions for other professional services firms.
teamspace comes in versions for several industries. Here are five besides the software vendor.
Management consulting
Days of clever people, utilisation across teams and fee invoicing.
Industry pageIT service providers
Projects and running operations, every hour on the right contract.
Industry pageCommon questions about software for software vendors
What separates a software house from a systems house?
A software house makes its own product and sells its licences, maintenance and further development. A systems house also trades third-party hardware and licences, which appear as separate items alongside the work on the invoice. Both run support and maintenance. Commercially, though, the centre of gravity is different: here the cadence of your own product, there the mixed business of trading and services. More on the overview for systems houses.
How do we see whether a customer request still fits into the next release?
The delivery date sits in the project as a milestone. Work packages and the people who build them hang off it. That puts the sum of hours required next to the hours that are free, with leave and absence already deducted. Whatever no longer fits, you move visibly to a later window. Capacity planning belongs to the enterprise edition, more on it under capacity planning.
Does this work if we do not ship quarterly?
Yes. The quarterly rhythm on this page is our own and stands here as an example. teamspace does not prescribe a cadence. A milestone is a date you set and assign work packages and staff to. Whether you ship monthly, every six weeks, twice a year or continuously changes nothing about that: before every date, the hours required stand next to the hours free. Vendors who ship continuously usually work without a delivery milestone at all and plan through sprints and capacity alone.
Does everything really have to run through the release cadence?
No, and it should not. Only what is built on the product itself is tied to the cadence. Rollouts run as separate projects per customer, with their own date and their own team. Licences, maintenance and support run on independently as ongoing contracts. teamspace holds these three strands on one set of data instead of spreading them across three tools, but it does not force them into a shared rhythm.
Can we work classic and agile in the same project?
Yes. teamspace supports classic, agile and hybrid ways of working, set up per project. A work package moves onto a Kanban or Scrum board and is worked on there. It stays the same item in two views, and booked time keeps flowing into the project's planned versus actual. Product backlog and sprint are there for it. More under project management.
How do we bill licence and maintenance fees on a recurring basis?
The order is not closed. It runs on as a line item over a duration and issues its own invoice, in the cycle you choose. For a house with its own product this is the revenue form: the recurring base carries you without anyone thinking about it each month. A price increase can take effect with the next period, so a running cycle does not break mid-month. Cancellation and pausing sit on the contract too. More under recurring invoices.
How do the support contract and the ticket fit together?
The support contract brings a set number of included hours, and tickets book their time against it. Once the allowance is used up, teamspace switches to time and material through the assignment rules. Nobody has to keep it in their head. The ticket also carries the response time you promised that customer, so support can see what comes first. More on service desk software.
Do we still need a ticketing system like Zendesk or Freshdesk alongside teamspace?
Usually not. The service desk in teamspace takes tickets from email, phone and web form, carries the promised response time as remaining time, and books the time straight onto the customer's support contract. That link to the contract is exactly what a separate ticketing tool lacks: the ticket sits there, the billing sits somewhere else. If you want to keep your existing tool, the line stays clean as long as billable time is booked in teamspace. More on service desk software.
Does the invoice really come out of the project?
Yes. Once the person handling it reports completion or handover, you trigger the invoice straight from the project. The line items come from the order and the booked time, not from a list someone assembles again. Unbilled time and costs can be reported on separately, so nothing sits around for months.
Does teamspace check whether our invoices have been paid?
In the enterprise edition, the online banking interface reconciles incoming payments daily. It only checks and never triggers a payment itself. If an invoice stays open, the staged dunning run starts, beginning with a payment reminder after a grace period. More on invoicing software.
Does teamspace replace Jira, Azure DevOps or GitLab?
No, and that is deliberate. Source code, version control, pull requests and the delivery pipeline stay in your development tools, whether that is Jira, Azure DevOps, GitHub or GitLab. teamspace manages the work around them: order, work package, date, booked time, ticket and invoice. The connection runs through the work package, which names the same task in both worlds. If you maintain tasks and commercial data twice today, teamspace takes over the commercial half, not the development.
How do lots of small licence invoices reach the accounts?
That is exactly where recurring billing starts to hurt: the sheer number. The invoices are created in the cycle you set as ZUGFeRD or XRechnung, without anyone opening a second tool, and go on as a batch. Through the certified interface to DATEV Unternehmen online, invoices and credit notes run straight into the DATEV cloud with no CSV file in between. That interface belongs to the enterprise edition. There is no direct connection for Lexware or Sage, where the standard export takes over.
Our customers ask about how we operate. What can we tell them?
Your customer's procurement will ask about the chain behind your administration, so concretely: teamspace runs in an ISO 27001 certified data centre in Frankfurt am Main, and processing takes place exclusively within the EU. The certification is held by the data centre, not by teamspace itself. That line is worth keeping clean in a tender. The contracting party is 5 POINT AG under German law, and released documents remain audit-proof in GoBD mode.
We are only twelve people. Is it worth it yet?
You do not need all of it at once. Start where the money is: billing licence and maintenance contracts cleanly and having the hours on the work package. Milestones with assigned capacity pay off as soon as more than a handful of developers compete for the same weeks, the service desk as your customer base grows. Adding more later means configuring, not migrating. You move between the light, office and enterprise editions without a data migration.
Does 5 POINT AG use teamspace itself?
Yes, completely. Invoicing, order processing, the quarterly release planning and the two-week sprint planning, support with service levels, HR and sales all run in teamspace. The walkthrough in the video further up shows what that looks like in detail.
Introductory call
Fifteen minutes to find out whether teamspace fits your cadence.
We talk about your delivery dates, your customer orders and your ongoing contracts. You get a clear assessment, not a presentation.